A comprehensive operational semantics of the SCOOP programming 

model 



Benjamin Morandi, Sebastian Nanz, and Bertrand Meyer 

Chair of Software Engineering, ETH Zurich, Switzerland 
f irstname . lastnsmieOinf . ethz . ch 
http : //se . inf . ethz . ch/ 



Abstract 

Operational semantics is a flexible but rigorous means to describe the meaning of programming 
languages. Small semantics are often preferred, for example to facilitate model checking. However, 
omitting too many details in a semantics limits results to a core language only, leaving a wide gap 
towards real implementations. In this paper we present a comprehensive semantics of the concurrent 
programming model SCOOP (Simple Concurrent Object-Oriented Programming). The semantics 
has been found detailed enough to guide an implementation of the SCOOP compiler and runtime 
system, and to detect and correct a variety of errors and ambiguities in the original informal speci- 
fication and prototype implementation. In our formal specification, we use abstract data types with 
preconditions and axioms to describe the state, and introduce a number of special operations to 
model the runtime system with our inference rules. This approach makes our large formal speci- 
fication manageable, providing a first step towards reference documents for specifying concurrent 
object-oriented languages based on operational semantics. 



1 Introduction 

Concurrent programming has become an important part of mainstream software development, caused 
by the widespread use of multicore processors. The notorious difficulty of writing concurrent programs 
correctly has on the other hand spawned work into novel language abstractions to express concurrency 



and synchronization. One such language is SCOOP |22 25 1, an object-oriented programming model for 
concurrency based on the idea of contracts. 

The main idea of SCOOP is to simplify the writing of correct concurrent programs for developers, 
who can use familiar concepts from object-oriented programming but are protected by the model from 
common concurrency errors such as data races. This is achieved by a runtime system that automatically 
takes care of operations such as obtaining and releasing of necessary locks, without the need for explicit 
program statements. While being based on conceptually simple ideas, the semantics of the language 
concepts and runtime system turns out to be very complex. 

The question is therefore how the semantics can be properly documented. The initial version of 
SCOOP has been defined in |22|, where all the main concepts are outlined but implementation aspects 
are neglected for the most part. A first prototype implementation was then introduced in [25 j , where the 
semantics was described only informally, with the exception of a formalization of the type system. In 
this paper we provide a full formalization of the operational behavior of SCOOP, specified by a structural 
operational semantics. The main contributions of the paper are: 

• A formal specification of SCOOP that treats all important language elements. 



Clarification and correction of the informal specification in |25 1. 
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This work does not provide a formal completeness and soundness proof with respect to an axiomatic 
semantics. Section [7] discusses this possibility as part of future work. This work focuses on a formal 
reference for a concurrent programming language. We argue that this formal reference reflects and 
corrects the informal description by following a systematic approach. 

This paper is structured as follows. Section[2]gives a brief overview of the main ideas of the SCOOP 
model to provide a basic intuition for the main part of the paper. Section [3] gives an overview of related 
work. Section |4] gives an overview of the considered language. The two following chapters contain the 
main parts of the formalization: Section[5]describes the state formalization and Section[6]the formaliza- 
tion of computations. Section [7] concludes and discusses future applications of the formalization. 

2 Background 

This section gives an overview of SCOOP. The starting idea is that every object is associated for its 
lifetime with a processor, called its handler. A processor is an autonomous thread of control capable of 
executing actions on objects. An object's class describes the possible actions sl?, features. A processor 
can be a CPU, but it can also be implemented in software, for example as a process or as a thread; any 
mechanism that can execute instructions sequentially is suitable as a processor. 

A variable x belonging to a processor can point to an object with the same handler {non-separate 
object), or to an object on another processor {separate object). In the first case, sl feature call x.f is non- 
separate: the handler of x executes the feature synchronously. In this context, x is called the target of the 
feature call. In the second case, the feature call is separate: the handler of x, i.e., the supplier, executes 
the call asynchronously on behalf of the requester, i.e., the client. The possibility of asynchronous calls 
is the main source of concurrent execution. The asynchronous nature of separate feature calls implies 
a distinction between a feature call and sl feature application: the client logs the call with the supplier 
(feature call) and moves on; only at some later time will the supplier actually execute the body (feature 
application). 

The producer-consumer problem serves as a simple illustration of these ideas. A root class defines 
the entities producer, consumer, and buffer. 

producer: separate PRODUCER 
consumer: separate CONSUMER 
buffer: separate BUFFER [INTEGER] 

The data structure for exchanging objects between the producer and the consumer. 

The keyword separate specifies that the referenced objects may be handled by a processor different 
from the current one. A creation instruction on a separate entity such as producer will create an object 
on another processor; by default the instruction also creates that processor. 

Both the producer and the consumer access an unbounded buffer in feature calls such as bujfer.put 
{n) and buffer.item. To ensure exclusive access, the consumer processor must lock the buffer processor 
before accessing the buffer. Such locking requirements of a feature must be expressed in the formal argu- 
ment list: any target of separate type within the feature must occur as a formal argument; the arguments' 
handlers are locked for the duration of the feature execution, thus preventing data races. Such targets 
are called controlled. For instance, in consume, buffer is a formal argument; the consumer processor has 
exclusive access to the buffer processor while executing consume. 

Condition synchronization relies on preconditions (after the require keyword) to express wait con- 
ditions. Any precondition of the form x.some .condition makes the execution of the feature wait until the 
condition is true. For example, the precondition of consume delays the execution until the buffer is not 
empty. As the buffer is unbounded, the corresponding producer feature does not need a wait condition. 
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consume {buffer, separate BUFFER [INTEGER]) 

Consume an item from the buffer. 

require 

not {buffer. count = 0) 
local 

consumed Jtem: INTEGER 
do 

consumedJtem := buffer. item 
end 

During a feature call, the consumer processor could pass its locks to the buffer processor if it has a 
lock that the buffer processor requires. This mechanism is known as lock passing. In such a case, the 
consumer processor would have to wait for the passed locks to return. In buffer. item, the buffer processor 
does not require any locks from the consumer processor; hence, the consumer processor does not have 
to wait due to lock passing. However, the runtime system ensures that the result of the call buffer.item 
is properly assigned to the entity consumedJtem using a mechanism called wait by necessity: while the 
consumer processor usually does not have to wait for an asynchronous call to finish, it will do so if it 
needs the result. 

The main part of the paper defines formally the implementation that gives rise to the behavior out- 
lined above. It also introduces advanced concepts and additional language elements, which cannot be 
covered in a brief overview, and shows how these give rise to a complexity which can only be dealt with 
satisfactorily with a formal specification. 

3 Related work 

The discussion is divided into work on SCOOP and work on other languages. 
3.1 Approaches for SCOOP 

In his dissertation, Nienaltowski |l25l worked out the details of an implementation of SCOOP as sug- 
gested by Meyer 1 22] , and provided a prototype implementation. The language semantics is described 
informally only, with the exception of the type system which is defined using an inference system. The 
informal description and the prototype contain various ambiguities and omissions, which we are able to 
clarify. 

Torshizi et al. |[32| have defined and implemented JSCOOP, a version of the SCOOP model for the 
Java language. Only the most important language elements are considered, and no attempt at formal- 
ization is made. In contrast, our specification and implementation [11] on top of Eiffel considers all 
language elements. We believe that our specification could help to extend JSCOOP to a full treatment of 
the language concepts. 

Brooke, Paige and Jacob |5| have used CSP p4| to give a semantics to SCOOP as described by 
Meyer [22]. Their initial hope was to use tools for analyzing CSP specifications, such as FDR, to au- 
tomatically check for deadlock in SCOOP programs, but found the size of the specification prohibitive. 
A benefit of their approach is that CSP provides the machinery needed to express concurrency and syn- 
chronization, leading to a relatively concise model. Our goal is to provide formal descriptions close to 
an actual implementation, and therefore prefer to design an own operational semantics, rather than going 
through the indirection of another process algebra. 

Structural operational semantics, introduced by Plotkin | [29| , is a flavor of operational semantics 
that has been used with great success to define various concurrent systems. Our specification uses this 
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style of semantics as well. To model SCOOP we also make use of established modeling concepts from 



process algebra, such as the notion of channels, which is present in most calculi such as CSP 1 14| or the 



TT-calculus |24 1. We use the theory of abstract data types (ADT) 1 19 1 to model the elements of a program 
text and to model the state of a SCOOP program. 

Ostroff et al. 1 ,28] describe a structural operational semantics for SCOOP in the refined version by 
Nienaltowski p5| . This operational semantics inspired our work, and we have attempted to stay close to 
their modeling ideas where possible, so that p8| can be viewed as a reduced version of the semantics we 
describe in this paper. While [28 ] covers some of the most significant aspects of SCOOP, it falls short of 
describing a number of other critical language concepts: in their reduced model, a query routine handled 
by some processor p must not make calls to a processor other than p; lock passing, expanded objects and 
the import mechanism, once routines, evaluation of (asynchronous) postconditions and invariants, and 
explicit processor tags are not considered. We clarify these aspects in this paper. Furthermore, |28J have 
pursued the goal to check temporal logic properties of SCOOP programs using their semantics and the 
SPIN model checker, but were limited to small programs by state space explosion. We have the different 
goal of providing a reference document for SCOOP, and thus don't have to sacrifice coverage of the 
language for keeping the specification small. 

3.2 Approaches for other concurrent programming languages 



Axum p3| is a concurrent programming language based on the actor model. In Axum, actors are called 
agents. An agent is an isolated runtime component that executes in parallel with other agents. The agents 
communicate with each other by sending messages through channels. Each channel has input ports, 
output ports, and a protocol. The ports are queues of messages. The protocol is a state machine that 
defines how the channel behaves. Schemas define the structure of messages. Besides message passing, 
Axum also provides domains - shared state between groups of actors. Erlang pO} and Scala | |27J are 
further examples of actor-based programming languages. 

Ceo is an extension of C# that integrates elements of the Join Calculus 1 12|. Ceo allows com- 



putations to be spawned off into different threads using asynchronous methods: while for synchronous 
methods the caller must wait until a routine completes, asynchronous methods return immediately while 
their body is scheduled for execution in another thread. Cft) supports so-called chords, which associate 
the body of a routine with more than one method; the body is executed only if all methods have been 
called. 

Another language is Cilk Q, which extends C with concurrency concepts. A method marked with 
the cilk keyword can be asynchronously spawned with the spawn keyword. The sync keyword requires 
the current method to wait for all previously spawned tasks to complete. An inlet function within a 
parent method receives the result of a spawned child method; the inlet functions of a parent method are 
guaranteed to execute atomically. Within an inlet function, the abort keyword tells the scheduler that any 
other child method spawned by the parent method can be aborted. Cilk also implements a work stealing 
mechanism to achieve high performance by dividing method executions efficiently among processors. 

Ada [ 15 1 defines tasks - units that can run in parallel. A task is declared within a procedure; it consists 
of a specification and an implementation. The task is activated when the procedure starts executing. The 
task specification can define a number of entry points with parameters; an entry point specifies an action 
the task can synchronize on. An accept statement within the task body indicates the point where the 
rendezvous can take place. Another task calls the entry point to take part in the rendezvous. With a select 
statement, one can wait for multiple entry points; alternatives may be guarded with boolean expressions. 
Ada defines protected objects - a monitor-like construct with guards instead of conditional variables. A 
protected object is declared within a procedure; it has a specification and an implementation. 

The Occam programming language fST] builds on the CSP process algebra |14|. A parallel con- 
struct defines a number of processes that execute concurrently; the parallel construct terminates when 
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all spawned processes terminated. Processes communicate with each other through named channels. 
The alternation construct defines a number of processes, where only one of them gets executed; a guard 
defines when a process can be executed. 

XIO [7], Fortress f2l, and Chapel [16] are based on the Partitioned Global Address Space (PGAS) 
model. PGAS uses a global shared memory. It defines portions on the global shared memory and as- 
sociates them to specific processors to improve performance and scalability. XIO provides important 
abstractions such as places, asynchronous methods, future invocations, and barriers. However, it places 
a considerable burden on programmers. Fortress offers implicit parallelization of loops and operations 
on data structures. Chapel provides a higher-level multithreaded parallel programming model with ab- 
stractions for data parallelism, task parallelism, and nested parallelism. 

Linda 1 13 1 is a coordination language to connect concurrent components; the components can be 
written in different programming languages. The coordination is based on a tuple space, which holds 
data tuples that can be stored and retrieved by the processes. Pattern matching is used to read and remove 
tuples; the operations block until a matching tuple is found. The eval construct creates a new process to 
evaluate an expression; the new process writes the evaluation result into the tuple space. Implementations 
of Linda can be found in several programming languages such as Java and C. 

For the related languages mentioned above, we are not aware of rigorous behavioral specifications, 
with the exception of C(0 and occam, which use the Join Calculus respectively CSP as the underlying 
model. For multi-threaded Java however, such formalizations have been attempted. 

Abraham, de Boer, de Roever, and Steffen [ 1 ] present an operational semantics for a subset of multi- 
threaded Java. They focus on the most important multi-threaded aspects, i.e., dynamic thread creation, 
thread termination, and re-entrant monitors. The semantics consists of two components: the semantics 
for isolated objects and the semantics for interacting objects. The authors want to use the semantics to 
develop a proof system that is based on an existing proof-system for isolated objects. A configuration 
is a set of instance configurations. An instance configuration contains the attribute values of one object. 
It also contains the local environment and the expression of each thread that is concurrently executing 
within the object. In modeling the state of a program, our semantics strictly separates the actions to 
be executed from the data. This makes it easier to derive implementations from the semantics because 
an implementation is likely to keep the program text and data separate. Abraham et al. use transition 
labels to synchronize inference rules. The labels allow an external observer to follow the transitions. Our 
semantics is a pure reduction semantics without labels because we do not require observable transitions. 

Cenciarelli, Knapp, Reus, and Wirsing [6] also describe an operational semantics for a larger subset 
of multi-threaded Java. They cover a larger number of multi-threaded aspects than [ 1 1. In particular they 
formalize Java's notification mechanism and the working memory. A configuration consists of a function 
that maps each thread to its expression and its local environments. The configuration also has a container 
with the objects and the static typing information. Lastly, the configuration consists of an event space. 
The event space is a partially ordered set of events that have been executed by the threads. The ordering 
reflects the order in which the events took place. An event space serves two purposes. First, it contains 
certain aspects of the state. For example, the lock and unlock actions tell us which thread owns which 
lock. Second, it records the history. A number of constraints state when an event space is valid. Hence, 
the event space indicates which further actions can take place. The authors use two different validity 
constraints for both Java's non-prescient semantics and its prescient semantics. Using this, they show 
that any prescient execution of a properly synchronized program can be simulated by a non-prescient 
execution. Compared to our semantics, there is no clean division between program text and the state and 
there is no clean division between the state and the typing information. 

Lochbihler I^O] suggest a different operational semantics for a large subset of multi-threaded Java. 
Just like ||6|, he covers the notification mechanism, but he does not formalize the working memory. He 
defines an instantiating semantics based on an extension of Jinja pM- Jinja is an operational seman- 
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tics for a subset of single-threaded Java. The instantiating semantics is used for the sequential case. 
Lochbihler defines a generic formal framework to lift the instantiating semantics to the concurrent case. 
The configuration of the instantiating semantics consists of the expression, a container with the objects, 
and the local environments. The state of the framework semantics consists of the lock status, the thread 
information with the thread's expression along with the thread's local environments, a container with the 
objects, and the wait sets. Lochbihler formalizes the notion of deadlocks, where deadlocks are either 
based on locks or on wait sets. He then proves that every program that satisfies certain criteria either pro- 
duces a final value, throws an exception, or deadlocks. He also shows that every such program preserves 
type safety. 

4 Language overview 

SCOOP is a programming language based on Eiffel, an object-oriented programming language, defined 
in the Eiffel ECMA standard [9] . SCOOP's concurrency model can be applied to other programming lan- 
guages as well. For this reason, this work does not focus on SCOOP, but on its concurrency model. This 
section defines a subset of SCOOP, reduced to the parts that are relevant for the concurrency model. It 
presents the syntax of the subset and a list of simplifications. It then discusses the program representation 
that this formalization assumes. 

4.1 Syntax 

The following EBNF grammar defines the set of all considered programs: 

program = {class jdeclaration} root 4>rocedure declaration ; 
root-procedure -declaration = "{" class .name "}" feature Jtame ; 
class -declaration = 
["expanded"] "class" class jiame 
["create" feature jiame {"," feature jiame}] 

"feature" ["{" class jiame {"," classjiame} "}"] {feature .declaration} 
["invariant" expression] 
"end " ; 

feature -declaration = routine -declaration \ attribute .declaration ; 
routine -declaration = 
feature Jiame ["(" entity .declaration {";" entity jdeclaration} ")"] [":" type] 
["require" expression] 
["local" {entity .declaration}] 
( "do " I "once ") 

{instruction ['";'"]} 
['"ensure'" expression] 
"end " ; 

attribute .declaration = entity .declaration ; 
entity -declaration = entity Jiame ":" type ; 

instruction = 
entity Jiame ":=" expression \ 

expression "." feature. name ["(" expression {"," expression} ")"] | 
"create" entity. name "." feature jiame ["(" expression {"," expression} ")"] | 
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"if expression "then" {instruction [";"]} "else" {instruction [";"]} "end" | 
"until" expression "loop" {instruction [";"]} "end" ; 

expression = 
literal \ 
entity jiame \ 

expression "." feature -name ["(" expression {"," expression} ")"] ; 
literal = boolean Jiteral \ integer Jiteral \ character Jiteral \ voidJiteral ; 
booleanJiteral = "True" | "False" ; 
integer Jiteral = ["-"]("0" | . . . | "9") {"0" | . . . | "9"} ; 
character Jiteral = " ' " "a" \...\ "z" \ "A" | . . . | "Z' | "0" | . . . | "9" " ' " ; 
voidJiteral = "Void" ; 

type^ 

[detachable Jag] 

["separate"] {explicit ^processor specification] 
classjiame {actual .generics] ; 
detachable Jag = 
"attached" | "detachable" ; 

explicit processor specification = 

qualified-explicit processor specification \ 

unqualified jexplicit .processor specification ; 
qualified^explicit^rocessor specification = 

"<" entityjiame "." "handler" ">" ; 
unqualified-explicit processor specification = 

"<" entity Jiame ">" ; 

class jiame = name ; 
feature Jiame = name ; 

name = {"a" | • . • | "z" \ "A" | . . . | "Z') {"a" | . . . | "z" \ "A" \ ...\ "Z'}; 
entity -name = feature -name \ "Result" | "Current" ; 

A class consists of a number of features. A feature is either a routine - a sequence of instructions 
- or an attribute - a data storage. If a routine returns a result, then it is called a. function; otherwise, 
it is called a procedure. If a routine is marked as a once routine (once keyword), then the routine gets 
executed only once in a given context. Functions and attributes are also called queries; routines are also 
called commands. A routine can define a precondition (require keyword) and a postcondition (ensure 
keyword). The enclosing class can define an invariant (invariant keyword). Each feature can be exported 
to a list of classes, so that only these classes can use the feature. A number of procedures are dedicated 
creation procedures. These procedures can be used in creation expression (create keyword) to create 
new objects. A class can be marked as an expanded class (expanded keyword). Objects of expanded 
classes get copied when they get passed around; objects of non-expanded classes get aliased. 

Formally, a type ? is a triple {d,p,c). The component d is the detachable tag, p is the processor tag, 
and c is the class type. The detachable tag d captures detachability. An entity of attached type (attached 
keyword), i.e., d = \,is statically guaranteed to store a value, i.e., to be non-void. An entity of detachable 
type (detachable keyword), i.e., d = 1, can be void. As discussed later, the detachable tag is also used 
for the selective locking mechanism to prevent a request queue from being locked. The processor tag p 
captures the locaUty of objects accessed by an entity of the type t. The processor tag p can be separate 
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(separate keyword without explicit processor specification), i.e., = T. The object attached to the entity 
of the type t is potentially handled by a different processor than the cunent processor. The processor tag p 
can be explicit (separate keyword with explicit processor specification), i.e., p = a. The object attached 
to the entity of the type t is handled by the processor specified by a. The processor tag p can be non- 
separate (no separate keyword), i.e. p = •■ The object attached to the entity of the type t is handled by 
the current processor. The processor tag p can denote no processor, i.e., p = ±. It is used in the type 
of the void reference. The explicit processor tag either has an unqualified or a qualified specification. 
An unqualified explicit processor specification, i.e., < p >, is based on a processor attribute p. The 
processor attribute p must have the type {\,», PROCESSOR) and it must be declared in the same class 
as the explicit processor specification or in one of the ancestors. The processor denoted by this explicit 
processor specification is the processor stored in p. A qualified explicit processor specification, i.e., 
< e. handler >, relies on an entity e occurring in the same class as the explicit processor specification or 
in one of the ancestors. The entity e must be a non-writable entity of attached type and the type of e must 
not have a qualified explicit processor tag. The processor denoted by this explicit processor specification 
is the same processor as the one of the object referenced by e. Explicit processor tags support precise 
reasoning about object locality. Entities declared with the same processor tag represent objects handled 
by the same processor. The absence of both the keywords is treated as if there was an attached keyword. 

4.2 Simplifications 

This work makes the following simplifications: 

• It does not consider unqualified feature calls. It expects all feature calls to be in the qualified form. 
This includes accesses to attributes of the current object in expressions. 

• It does not consider infix feature calls. It expects all feature calls in the non-infix form. For 
example, an expression x> y must be transformed into the equivalent form x.is-greater(y). 

• It simplifies the automatic initialization of entities. All entities, except for the current object entity, 
are initialized with the void reference. 

• It neglects exception handling. The exception handling mechanism for SCOOP is still under de- 
velopment. 

• It does not consider garbage collection because garbage collection is not refined in the SCOOP 
model. 

• It does not consider agents. From this work's point of view, agents are normal objects. 



4.3 Intermediate representation 

For the purpose of the formalization, this work assumes that a program is given in an enriched interme- 
diate representation, where the syntactical elements are replaced with instances of abstract data types. 
In particular, it assumes ADTs for class types, features, expressions, and instructions. Figure [T] summa- 
rizes these ADTs. The instances of CLASS_TYPE are all possible class types, i.e., the types directly 
defined by all non-generic classes and all possible generic derivations of all possible generic classes. 



Section 5.1.3 discusses how to get these instances. The ADT CLASS_TYPE defines a name query 
name. Each class type can either be a reference class type or an expanded class type. The queries is.ref 
and is_exp provide this information. Each class type defines a number of features. These features can 
be divided into attributes, functions, and procedures. An attribute of an object stores a value. A func- 
tion performs a computation and returns the result. This computation must not modify the state. A 
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CLASS_TYPE 



+name : NAME 
+is_ref : BOOLEAN 
+is_exp : BOOLEAN 
+attributes : TUPLE 
+functions : TUPLE 
+procedures : TUPLE 
+inv_exists : BOOLEAN 
+inv : EXPRESSION 



+feature_by_name(in name : NAME) : FEATURE 



FEATURE 



+name : NAME 
+formals : TUPLE 
+is_once : BOOLEAN 
+pre_exists : BOOLEAN 
+pre : EXPRESSION 
+post_exists ; BOOLEAN 
+post : EXPRESSION 
+locaIs : TUPLE 
+body : TUPLE 
+is_exported : BOOLEAN 
+class_type ; CLASS_TYPE 



EXPRESSION 



T 










1 


ENTITY 




LTTERAL 




QUERY_CALL 


+name : NAME 
+context_feature : FEATURE 


+obj : OBJECT 
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Figure 1 : ADTs for the intermediate representation 



procedure performs a computation that modifies the state. Functions and procedures are also known as 
routines. For each of these categories, CLASS-TYPE defines a query that returns a tuple of features. 
The query attributes returns a tuple of attributes, the query functions returns a tuple of functions, and 
the query procedures returns a tuple of procedures. If the name of a feature is known, then the query 
feature Jby jiame can be used to get the feature with that name. Each class type can have an invariant. The 
query inv. exists indicates whether such an invariant exists. In case an invariant exists, it can be accessed 
with the query inv as an expression. One of the instances of CLASS _TYPE is BOOLEAN . This class 
type is expanded and it has an attribute with name item. The value of this attribute is the represented 
boolean value, i.e., an instance of BOOLEAN. 

In this formalization, a feature is an instance of FEATURE. The name of the feature can be retrieved 
with the query name and the formal arguments are given by the query formals that returns a tuple with 
the formal arguments as entities. Whether or not the feature is a once feature can be determined using 
the query is-once. The queries pre and post return an expression for the precondition respectively the 
postcondition, provided that the queries pre-exists and post. exists indicate that the assertions exist. Next, 
there is the query locals that gives the locals of the feature as entities. The query body returns the body 
of the feature as a tuple of instructions. Each feature is either exported or not. A non-exported feature 
is only available in calls on the current object within the class that declared the feature. An exported 
feature can be called by other clients as well. The query exported returns whether a feature is exported or 
not. Lastly, each feature has a link to the class it belongs to. This is given by the query class Jype. This 
can be used for example to retrieve the invariant that must be preserved by a feature. For each feature 
category, there is an ADT that inherits from the FEATURE ADT. 

Expressions can either be entities, literals, or query calls. Every expression is an instance of 
EXPRESSION. For each form of expression, there is one ADT that inherits from the EXPRESSION 
ADT. For entities there is an ADT with a query name that returns the name of an entity. A query 
context -feature links an entity to the feature in which the entity is declared. A literal is a character se- 
quence that represents a constant value. As such, literals count as manifest expressions - programming 
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constructs whose values can be deduced by the compiler statically. Literals are instances of an ADT 
LITERAL. This ADT has instances for booleans, integers, characters, and the void literal. Each literal 
except the void literal can be translated into an object with the query obj. This object matches the hteral 
in both type and value. The following notation describes instances of EXPRESSION: 

e = w\b \ e.f{e,...,e) 

Here, w is an element of LITERAL, b is an instance of ENTITY, and / is an instance of FEATURE. 
For instructions, there is an ADT INSTRUCTION and an ADT for each kind of instruction. The fol- 
lowing notation describes such instances: 

b:=e\ 

e.f{e,...,e) \ 

create b.f{e, . . . ,e) | 

i{ e then [^l;^}*] else [il;^}*] end | 

until e loop end 

Here, s stands either for an instance of INSTRUCTION or an operation. Instructions are actions 
that occur in the intermediate representation (user syntax). Operations are actions that do not explicitly 
occur in the intermediate representation (run-time syntax). 

This work builds on an existing type system formalization. It assumes the existence of a typing 
environment that can be queried for type information. 

4.4 Basic ADTs 

This work assumes an ADT BOOLEAN for the two boolean values true and false along with the typical 
boolean operators. It assumes an ADT NAME for names and an ADT ID for identifiers. 

Based on these ADTs, there is a generic ADT SET[G], whose instances are sets of elements with 
type G. A set can be created with a call to the constructor make and it can be populated with a call to the 
command add that takes an element and returns a new set containing the element. However, we prefer 
to define an instance of this ADT with set inference or with a set expression {xi, . . . ,x„}. A set can be 
inspected with the query has that returns whether an element is part of the set or not. The G notation is 
an alias of the has query. A query is^empty tells us whether the set is empty or not, and the query count 
returns the number of elements in the set. 

A tuple is an ordered list of elements. This work assumes a generic ADT TUPLE that takes zero or 
more generic parameters for the types of each tuple element. Each generic parameter G restricts the set 
of possible tuples to the ones who have an element of type G in the respective position. For example, the 
instances of TUPLE without any generic parameters are all possible tuples. The instances of TUPLE [A] 
are all tuples whose first elements are of type A. Note that this also includes tuples with more than one 
element, as long as the first element is of type A. A tuple can be constructed with a call to the constructor 
make. Elements can be added to the end of the tuple with a call to the command add. We prefer to 
construct tuples with tuple expression (xi, . . . ,x„). The query has checks whether an element is part of 
the tuple or not and the query is. empty checks whether the tuple is empty or not. The query count returns 
the number of elements in the tuple. 

Furthermore, this work assumes a generic ADT STACK [G] for stacks with elements of type G. A 
stack gets constructed with a call to make. An element gets pushed with a call to push and is then 
available through the query top. The element can then be popped with a call to pop. A query is^empty 
returns whether the stack is empty or not. Another query ^af returns a set of type SET[G]. This set 
contains all the elements in the stack. 
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Next, this work assumes an ADT MAP[K, G] for maps with keys of type K and values of type G. As 
the name suggests, a map associates keys to values. A map gets constructed with a call to the constructor 
make. An association can be added with a call to add where the first argument is the key and the second 
argument is the value. The set of all possible keys can be retrieved with a call to the query keys. The 
value for a specific key in this key set is returned by the query val. 



5 State formalization 

This section provides a formalization of the state of a SCOOP program. This is necessary to describe the 
effect of SCOOP constructs on the state. The discussion starts with the general approach and continues 
with the description of the state. 



5.1 General approach 

This work considers the state of a SCOOP program to be a data structure that can be created, modified, 
and queried through features. For the specification of the state, this work uses Liskov's ADT theory |19| . 
The discussion begins with a justification and the consequences of this choice. The discussion finishes 
with an explanation on how to get types for elements in the intermediate representation. 



5.1.1 Abstract data types 



Meyer's work on a three-level approach to the description of data structure |21 1 defines three levels on 
which a data structure can be described: functional, constructive, and physical. The functional specifica- 
tion is an algebraic approach that uses an implicit characterization of the data structure. The constructive 
specification provides a means to construct instances of the data structure. The instances constructed like 
this are mathematical entities. A physical description describes the layout of instances in memory. The 
constructive specification can be derived from the functional specification and the physical description 
can be derived from the constructive description. 

This work models the state as an ADT instance, on the functional level in the hierarchy described 
above. This has several reasons. First of all, ADT theory allows us to describe the state on an abstract 
level without dealing with aspects of the implementation. The constructive and the physical level can be 
derived from the ADTs on the functional level. Second, ADT theory allows us to modularize the state. 
Different concerns of the state can be modeled as individual ADTs, while a single ADT can be used 
to consolidate the individual ADTs. This improves understandability and maintainability of the state 
description. Lastly, ADT theory is well established and suitable for the task at hand. 

An ADT t consists of queries, commands, and constructors. A query of t provides information about 
an instance of t. The query takes as a first argument the target of type t, which is the instance to be 
queried. Next to the target, the query can take further arguments with types t\^,. .. ,t„. Finally, the query 
returns a result of a type f„+i . The declaration of this query is written as query : f f„ . 

For flexibility reasons, this work uses the curried form (as in Haskell) instead of the equivalent Cartesian 
form query: t x ti x . . . x tn ^ t„+i. A command of t returns an updated instance according to the 
command's semantics. The declaration of a command looks much like the one of a query. However, the 
result of the command is an instance of t. To simplify the discussions, the following terminology is used: 
an update of an ADT instance is the act of calling a command on the instance; the updated instance is 
the result of the command. A constructor of t creates a new instance of t. In contrast to queries and 
commands, a constructor does not take the target as the first argument because its purpose is to create a 
new instance. 

To describe an instance of an ADT, one can build an expression that starts with a constructor call. 
This expression can then be used as the first actual argument of a command call. The resulting expression 
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can then be used as the first actual argument of the next command. This leads to a nested expression, in 
which the first feature call is in the root of the expression and the last feature call is on the outside of the 
expression. The instance described in such a way can then be queried. We find this functional notation 
hard to read. Therefore we use an equivalent object-oriented notation in which the first feature call is on 
the left and the last feature call is on the right. The main idea is not to write targets as arguments, but to 
write a target in front of the feature name and to use a dot to separate the two parts from each other. This 
leads to the following translation between the functional notation and the object-oriented notation: 

• The query expression queTy{eo,ei,. ..,e„) written in functional notation is equivalent to the ex- 
pression eo.query{ei,. . . ,e„) written in object-oriented notation. 

• The command expression command{eo,ei,. ..,€„) written in functional notation is equivalent to 
the expression eQ.command{e\ ,...,e„) written in object-oriented notation. 

• The creation expression constructor {ei,. ..,€„) for an instance of an ADT t written in functional 
notation is equivalent to the expression new t .constructor{ei, . . . ,e„) written in object-oriented 
notation. 

The identity of an ADT instance is given by its query values. Hence, the following holds for all 
ADTs t: newt. constructor {e I,..., Cn) = new t.constructor{ei, . . . ,e„). 

Example 1 (Functional notation versus object-oriented notation). The expression in functional nota- 
tion is_empty{pop{push{new STACK[PROC].ma;^e,p))) can be written in object-oriented notation as 
new STACK[PROC] .make .push{p) .pop. is. empty. □ 

Each feature can have a precondition that must be satisfied before the feature gets called. A precondi- 
tion is expressed as a number of assertions on the target and the arguments. A feature with a precondition 
is a partial feature. A partial feature is a feature whose domain is restricted. Such a partial feature is in- 
dicated with a crossed arrow after the type of each formal argument that got restricted by the feature's 
precondition. Non-restricted formal arguments are indicated with a normal arrow — >. The effect of an 
ADT command is described in a number of axioms. This work deviates from the practice of bundling all 
axioms for a specific ADT. Instead, all the axioms for a specific feature occur in the feature's declaration. 
Note that this work does not aspire a sufficiently complete ADT because this would lead to rule explo- 
sion. An ADT is sufficiently complete if its axioms make it possible to reduce any query expression to 
a form that does not involve an instance of the ADT. This requires that the axioms describe the effect of 
each command on each query. This work follows the practice to describe the effect of each command of 
an ADT on all the queries of the ADT that have been changed by the command. Unmentioned queries 
are unchanged. 

Example 2 ( Command declaration). The following declaration shows a command to set the value of an 
attribute / of an object o to the value v. The value can either be a reference or a processor. The command 
takes the object as the target and returns an updated object whose attribute value is set. 

setMtt.val : OBJ ATTRIBUTE ^ REF U PROC OBJ 
o.setMttJval{f, v) require 

o. class Jype. attributes. has{f) 
axioms 

o.setjattJval{f,v).att_val{f) =v 

The command states in its precondition that the class type of the target object o must have an attribute 
/. This is expressed as an assertion after the require keyword. The part in front of the require keyword 
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gives names to the target and the arguments. Note that the precondition makes the command partial. The 
updated object has the value of its attribute / set to v. This is stated as an axiom after the ensure keyword. 
□ 

So far the discussion covered queries, commands, and constructors for ADTs. This work extends the 
ADT theory with the notion of auxiliary features. Auxiliary features are convenience features that are 
not essential for the definition of the ADT, but nevertheless useful. 

The remainder of this work declares various ADTs to model the state of a SCOOP program. Unless it 
would create confusion, it uses the same name for an instance of an ADT and the corresponding domain 
element. For example, the instance of the ADT OBJ is called an object. 



5.1.2 Identifier management 

This formalization models objects, references, and processors. All of these domain elements have an 
identity. These identities are automatically managed by the runtime system. The work by Khoshafian 
and Copeland [ 17] on different levels of object identity provides good reasons for this decision. They 
introduce a scale that starts with identities given by the value, goes on with user-supplied identities, and 
ends with built-in identities. Built-in identities have the advantage that the identities are preserved in 
case of modifications. According to this hierarchy, our domain elements have a built-in identity. One 
straightforward way to reflect this, is to model each domain element as an instance of an ADT. However, 
this direct approach does not properly capture the identities of the domain elements because the identity 
of an ADT instance is not built-in, but based on the query values. This section describes a way to 
introduce built-in identities for ADT instances. 

To model domain elements with built-in identities, one can define an ADT with an identifier query. 
A number of ADT instances represent a single domain element over time. Each of the ADT instances 
has the same value for the identifier query. A modification of the domain element can then be modeled 
as a new ADT instance where the value of the identity query is preserved and all other queries modulo 
the modification are preserved. 

For this to work, the formalization ensures that no two ADT instances that model different domain 
elements have the same identity. This is ensured with a fresh identifier for each ADT instance that models 
a new domain element. For this purpose, the universal stateful query newJd returns a fresh identifier. 
The formalization then preserves the identifier in every modification. 



5.1.3 Typing environment 



Nienaltowski |25| presents a formalization of the SCOOP type system for a core of SCOOP called 
SCOOPc. The type system formalization is part of the base for this work. The typing environment T 
contains the class hierarchy of a SCOOP program along with all the type definitions of all features and 
entities. Type rules allow us to derive conclusions. 

The notation T\- e :t denotes that expression e is of type t. Based on this derivation, the function 
type.of{r,e) denotes the type of expression e in the typing environment P. The type rules can be used 
to check whether an expression is controlled or not. In a SCOOP program, each processor p that wants 
to apply a feature / must make sure that all the processors (gi, . . . ,g„) of all attached actual arguments 
of / are exclusively available on behalf of processor p. This guarantees exclusive access on all objects 
handled by processors {p,q\,. . . ,qn}- Note that processor p is in this set too because p can exclusively 
access its objects during a feature execution. For safety, the type system only allows feature calls in / 
on expressions, where the type system can derive that the value of the expression is a reference to an 
object and this object is handled by one of the processors {p,q\,. . . Such an expression is called 
controlled. Whether or not an expression is controlled can be determined through the context in which 
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the expression appears and the type of the expression. The context can either be the enclosing class, in 
case of expressions in invariants, or it can be the enclosing feature, in case of all other expressions. To 
be more precise, an expression e of type t = {d,p,c) is controlled if and only if t is attached, i.e., d = I, 
and t satisfies at least one of the following conditions: 

• The expression e is non-separate, i.e., p = *. 

• The expression e appears in a routine / that has an attached formal argument w with the same 
handler as e, i.e., p = w.handler. 

The second condition is satisfied if and only if at least one of the following conditions is true: 

• The expression e appears as an attached formal argument of /. 

• The expression e has a qualified exphcit processor specification w.handler and w is an attached 
formal argument of /. 

• The expression e has an unqualified explicit processor specification p, and some attached formal 
argument of / has p as its unqualified explicit processor specification. 

The notation T h controlled{t) denotes that an expression e of type t is controlled. To establish the 
derivation T h controlled{t) one has to find an attached formal argument w in the enclosing routine such 
that the types suggest that w and e are handled by the same processor or one has the estabUsh that the 
type t is non-separate. One can therefore be sure that whenever an expression e is controlled, either a 
matching formal argument exists or its type is non-separate. For the first case, the formal argument is 
the controlling entity for e. For the second case, the current entity is the controlling entity. Although not 
present in Nienaltowski's formahzation of the type system, this work introduces a new derivation T\-y = 
controlling. entity {e) that returns the controlling entity y for an expression e as an instance of ENTITY. 
This notion is essential to determine the handler of any controlled expression without evaluating the 
expression. One can simply determine the controlling entity and then determine the handler of the 
controlling entity. 

5.2 Components of the state 

The state is divided into three parts: the regions, the heap, and the store. The main purpose of the heap 
is to keep track of objects and to maintain the mapping of references to objects. It also maintains the 
once status of once routines, i.e., whether a once routine is fresh on a processor. The regions manage 
the association between objects and processors. Objects that are handled by the same processor form a 
region. The regions are also concerned with locking. The store is a map of names to references. It maps 
names of formal argument, names of local variables, the name of the current object entity, and the name 
of the result entity to references. A state ADT models the state with one query for each of the three parts. 

regions: STATE REG 
heap: STATE ^ HEAP 
store: STATE ^ STORE 

The next few sections introduce ADTs for each of the parts. A later section presents the state ADT. 



14 



5.3 Heap ADT 



The heap keeps track of the objects and the references associated to them. It also keeps track of the 
status of once routines. This section first defines an ADT for objects and references. Then it introduces 
an ADT for the heap. 

5.3.1 Objects and references 

There are two kinds of class types in the SCOOP type system: reference class types and expanded class 
types. The main difference lies in the semantics of using an instance of the types as the source of an 
attachment, such as assignment or argument passing. If an object of reference class type is the source of 
an attachment, then the reference to the object gets copied over to the destination of the attachment. The 
object is then accessible both through the source of the attachment as well as through the destination of 
the attachment. If an object of expanded class type is the source of an attachment, then a copy of the 
object gets attached to the destination of the attachment. The details can be found in Section 7.4 of the 
Eiffel ECMA standard |9|. 

This formalization takes a unified view on objects and references that is compatible with the se- 
mantics described in the Eiffel ECMA standard. It does not consider objects of expanded class type as 
sub-objects in other objects or in an environment. Instead it locates expanded objects on the heap, just 
like objects of reference class type. For each object there is exactly one reference. Assigning references 
to objects of expanded type has one major advantage for the formalization. If an ADT instance x that 
models an object gets updated, then one gets a new ADT instance y. If one would model expanded 
objects as sub-objects stored in other objects or in environments, then such an update might trigger a 
cascade of ADT instance updates: each ADT instance that has a: as a query value would have to be 
updated with y, and so on. A consequent usage of references avoids this issue. To do the update, one 
simply alters the reference to x so that it points to y from now on. 

The ADT REF models references with an identity query id and a constructor make. The constructor 
uses the query newJd to create a fresh identifier for the newly created reference. The void reference void 
is an instance of this ADT. 

id: REF-;>ID 



make: REF 
axioms 

make.id = newJd 

The ADT OBJ models objects. Each object has a query id for its identifier, a query class Jype for 
its class type, and a query att_val for its attribute values. An object can only have attribute values for 
attributes that are defined in its class type. 

id: OBJ ^ ID 

class Jype: OBJ ^ CLASS _TYPE 



att.val : OBJ ^ ATTRIBUTE ^ REF U PROC 

o.attJval{f) require 

o. class Jype. attributes. has{f) 
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The attribute values of an object can be modified with the command set_att_val. Only the attribute 
values for attributes that are defined in the class type can be modified. The result is an updated object 
where the attribute value of / is set to v. Note that the value can either be a reference or a processor. 
Processor values are necessary to support processor attributes. 

setMtt.val : OBJ ATTRIBUTE ^ REF U PROC OBJ 
o.setMtt-val{f, v) require 

o. class Jype. attributes. has{f) 
axioms 

o.set_att_val{f,v).att_val{f) =v 

The constructor make can be used to create a new object. It creates a new object with the given class 
type. The new object has a new identifier that is given by the query newJd. The constructor initializes 
all the attribute values of the new object with the void reference. 

make : CLASS TYPE ^ OBJ 
axioms 

make{c).id = newJd 
make{c). class Jype = c 
V/ G {1, . . . ,n} : make{c).att-val{ai) = void 
where 

{ai,. . . ,a„}'=^ c. attributes 

An object can also be copied with the auxiliary query copy. This is important for expanded objects 
with copy semantics. The copied object has the same class type and the same attribute values as the 
original object, but it has a new identity. The new identity comes from the call to the constructor make. 

copy: OBJ ^ OBJ 
axioms 

o.copy = make[o. class -type) 
.setj2ttJval{a\,o.attJval{ai)) 

.setj2tt-val{a„,o.att-val{an)) 
where 

n '== o. class Jype. attributes. count 
{ai,. . . ,a„}'^= o. class Jype. attributes 

5.3.2 Mapping from references to objects 

The ADT HEAP makes use of OBJ and REF to model the mapping from references to objects. For this 
purpose, it declares the query objs to store all the objects on the heap and it declares the query refs to get 
all the references to these objects. The reference void is not part of the reference set. The query ref-obj 
defines the actual mapping. For each reference in refs an object in objs gets returned. The ADT also 
declares the query last_added_obj to keep track of the last object that has been added to the heap. It uses 
this query to define the effect of adding an object to the heap. 

objs: HEAP ^ SET [OBJ] 
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refs : HEAP ^ SET[REF] 



ref.obj : HEAP ^ REF ^ OBJ 

h.ref-obj{r) require 
h.refs.has{r) 

lastjadded.obj: HEAP OBJ 
h.last_added-obj require 
^h.objs. is. empty 

A number of commands are responsible for adding objects and for altering the mapping of references 
to objects. The command add_obj takes an object o and adds it to the heap. The result of the command is 
a new heap with the object o and a new reference that points to o. The newly added object is indicated in 
the query last. added. obj. Note that this command does not create a new object. It simply adds an object 
that has been provided as an argument. The command requires that the object is not yet part of the heap. 

add-obj: HEAP OBJ ^ HEAP 
h.add.obj{o) require 

Vm G h.objs: u.id ^ odd 
\la G o. class Jype. attributes: 

o.attJval{d) G REF — >■ {o.attJval{a) = void\/ h.refs.has{o.attJval{a))) 
axioms 

h.add-obj(o) .ohjs = h.objsU{o} 
h. add -obj{o). refs = h.refsU{r} 
h.add obj{o).ref obj{r) = o 
h. add jobj{o). last. added -obj = o 
where 

r new 'REF. make 

If an object that is already part of the heap gets updated, then it is necessary to update the mapping 
from the reference to the object on the heap. This can be done with the command update-ref that takes a 
reference r and an updated object o and returns a heap where the reference r points to o. The command 
requires that r is a valid reference and that o is an updated version of the original object. Because the 
remaining part of the state only deals with references rather than objects directly, a reference update does 
not require an update of these parts. 

update j-ef : HEAP REF ^ OBJ ^ HEAP 

h.updatejref{r,o) require 

h.refs.hasir) 

o.id = h.ref -obj{r).id 

Va G o. class Jype. attributes : 

o.attJval{a) G REF (p.attjval{a) = voidM h.ref s.has{o.attJval{a))) 
axioms 

h. update. ref{r, o) .objs.has{o) 

o 7^ h.ref -obj{r) — ^ -^h.updatej-ef{r,o).objs.has{h.ref-obj{r)) 
h. update -ref{r,o).ref-obj{r) = o 

h.lastjiddedjobj = h.ref .obj{r) h.updatej-ef{r,o).lastjadded.obj = o 



17 



So far HEAP covers the mapping from references to objects. Occasionally it is necessary to have 
the inverse mapping. The commands addjobj and update .ref ensure that there is exactly one reference 
for each object on the heap. Thus it is possible to define the inverse query ref as an auxiliary query. 

ref : HEAP OBJ ^ REF 
h.ref{o) require 
h.objs.has{o) 
axioms 

h.refjobj{h.ref{o)) = o 

5.3.3 Once routines 

A once routine can either be a once function or a once procedure. A once routine gets executed at most 
once in a certain context. If a once routine has been executed in the context, then it is called non-fresh in 
the context. Otherwise it is called fresh in the context. The context is either the set of all processors in 
the system or a single processor. The heap remembers which once routines are fresh. For this purpose, 
HEAP declares the queries is fresh and once .result. For any processor p and any once routine /, the 
query is fresh states whether / is fresh on p or not. For a once function / that is not fresh on a processor 
p, the query once result returns the result of / on p. 

is fresh ■ HEAP ^ PROC ^ FEATURE ^ BOOLEAN 

h.isfresh{p,f) require 
f.isjonce 

once. result: HEAP PROC FEATURE ^ REF 
h.oncejresult{p,f) require 
/ G FUNCTION A/. w_once 
-^h.isfresh{pj) 

Two commands change the once status of a fresh once routine to non-fresh. One version works for 
once functions and the other one for once procedures. Both commands take the once routine / and the 
processor p. The version for once functions also takes a once result r. The two commands implement 
the semantics for once routines: a once routine has either a once per system or a once per processor 
semantics. Once functions declared as separate with or without an explicit processor specification have 
the once per system semantics. In this case, the command set jonce frnc jiot fresh defines / as non-fresh 
on all processors. Once functions with a non-separate result type have the once per processor semantics. 
In this case, the command set jonce frnc Jiot fresh sets / as non-fresh on p with the once result r. Once 
procedures have the once per processor semantics. In this case, the command set once procjiot fresh 
sets / as non-fresh on p. 

set. once frnc _not fresh : HEAP PROC FEATURE ^ REF ^ HEAP 

h.set-oncefrncJiotfresh{p,f, r) require 

/ G FUNCTION A/. jj_once 

r 7^ void — > h.refs.has{r) 
axioms 

{3d,c: r\- f :{d,;c)) 

-^h.setjoncefrncJiotfresh{p,f,r).isfresh{p,f)A 

h.set-once frnc Jiotfresh{p,f, r). once j'esult{p,f) = r 
{3d,c: f:{d,p,c)Ap^»)^yqeVROC: 

^h.setjoncefrncjiotfresh{p, f, r) .isfresh{q, /) A 

h.set. once frnc Jiotfresh{p^f ,r). once j-esult{q,f) = r 
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set _once4)rocjiot. fresh: HEAP PROC FEATURE ^ HEAP 
h.set-once-procJiot-fresh{p,f) require 

/ G PROCEDURE A /./5_o?ice 
axioms 

^h.set_once_procjiot_fresh{p,f).isJ'resh(p,f) 
5.3.4 Creation 

A new heap can be created with the constructor make. A new heap has no objects and no references. All 
once routines are marked as fresh on all processors. 

make: HEAP 
axioms 

make.objs . is^empty 
make, refs .is^empty 

\/p G PROC, / G FEATURE: f.isjonce make.is_fresh{p,f) 
5.4 Regions ADT 

The heap is partitioned into disjoint regions, and each region is assigned to exactly one processor. This 
concept relates to the concept of a ken in Schmidt's work |30} . The processor of a region is the handler 
of all the objects in the region. Regions are also used to maintain locks. The following discussion first 
describes an ADT for processor and then describes an ADT for regions. 

5.4.1 Processors 

A processor is an autonomous thread of control capable of executing features on objects. Each processor 
is responsible for a set of objects. As such a processor is called the handler of its associated objects. Each 
object is assigned to exactly one processor that is the authority of feature executions on this object. If a 
processor q wants to call a feature on an object handled by a different processor p, then q needs to send 
a feature request to processor p. This is where the request queue of processor p comes into place. The 
request queue keeps track of features to be executed on behalf of other processors. Processor q can add a 
request to this queue and processor p will execute the request as soon as it executed all previous requests 
in the request queue. Processor p uses its call stack to execute the feature request at the beginning of the 
request queue. The call stack is responsible for the order of feature executions on the same processor. In 
a situation of a non-separate call, the call stack ensures that the calling feature execution resumes once 
the called feature execution terminated. The interaction between the call stack and the request queue is 
best described with the following loop through which each processor goes: 

1 . Idle wait. If both the call stack and the request queue are empty, then wait for new requests to be 
enqueued. 

2. Request scheduling. If the call stack is empty but the request queue is not empty, then dequeue an 
item and push it onto the call stack. 

3. Request processing. If there is an item on the call stack, then pop the item from the call stack and 
process it. If the item is a feature request, then apply the feature. If the item is an operation, then 
execute the operation. 
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For each processor there is a request queue lock and a call stack lock. A lock on the request queue 
grants permission to add a feature request to the end of the request queue. A lock on the call stack grants 
permission to add a feature request to the top of the call stack. Before processor q can add a request to p's 
request queue, it must have a lock on this request queue. Otherwise another processor could intervene. 
Once processor q is done with the request queue of processor p it can add an unlock operation to the 
end of the request queue. This makes sure that the request queue lock of p will be released after all the 
previous feature requests have been executed. Similarly, processor p must have a lock on its call stack 
to add features to its call stack. Initially, each processor has a lock on its own call stack and its request 
queue is not locked. 

Processor q could also make a synchronous call to p. However q might be in possession of some 
locks that are necessary for the execution of the resulting feature request on p. In such a situation, q is 
waiting for the synchronous call to terminate and p is waiting for locks to be available. According to the 
conditions given by Coffman et al. [8^] a deadlock occurred. This can be avoided if q temporarily passes 
its locks to the p. This allows p to finish the execution and hence q can continue. 

Clarification 1 (Request queue locks and call stack locks). The notion of request queue locks and call 
stack locks was not present in Nienaltowski's [25] definition of SCOOP. He defines one lock for each 
processor. A lock on a processor means exclusive access to the whole processor. This lock model is 
not sufficient to describe SCOOP. In particular, this lock model creates a contradiction with respect to 
separate callbacks. A separate callback is a feature call in which processor q made a direct or indirect 
call to processor p and now p is calling back processor q. The separate callback is only possible if p has 
a lock on q. However, p does not necessarily have this lock because the lock might be in possession of 
the processor that locked q in the first place. Request queue locks and call stack locks allow us to clarify 
the situation. Thus we propose a new lock model with request queue locks and call stack locks. 

The lock model used in Nienaltowski's work p5| is an abstraction of the new lock model. The 
abstraction works under the assumption that no processor passes its locks. Under this assumption each 
processor keeps its call stack lock. In this abstraction, the request queue lock on a processor p is called 
the lock on p. As long as the call stack lock on a processor p is in possession of p, a request queue lock 
on p in possession of a processor q means that processor p will be executing new feature requests in the 
request queue exclusively on behalf of q. This means that a request queue lock grants exclusive access 
to all the objects handled by p. Transferring this insight to the abstraction, a lock on processor p denotes 
exclusive access to the objects handled by p. □ 

The formalization defines the ADT PROC for processors. A processor has an identifier stored in the 
query id. 

id: PROC ^ ID 

The constructor make returns a new processor with a fresh identifier. The fresh identifier is defined 
through the query newJd. 

make: PROC 
axioms 

make.id = newJd 

The ADT PROC is very simple. It neither takes care of the mapping from processors to the handled 
objects nor does it take care of the locks. These aspects are taken care of by the ADT for regions. 
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5.4.2 Mapping of processors to objects and locking 

This section introduces the ADT REG for regions. This ADT declares a query procs that keeps track 
of all the processors in the system. The query handled jobjs defines a set of handled objects for each 
processor in procs. Finally, the query last. added. proc denotes the last processor that has been added to 
procs. 

procs: REG ^ SET[PROC] 

handled _ohjs: REG -> PROC ^ SET[OBJ] 
k.handled.objs{p) require 
k.procs.has{p) 

lastjaddedjproc: REG PROC 
k.last_added-proc require 
^k.procs.isjempty 

Next to the queries that are concerned with the mapping from processors to objects, there are a 
number of queries that deal with locking. The feature rq Jacked states whether the request queue of a 
processor in procs is locked or not. Similarly, the feature cs docked states whether the call stack is locked. 

The remaining queries specify the owners of the locks. For this, the formalization distinguishes be- 
tween obtained and retrieved locks. Obtained locks are locks that got acquired by a processor. Retrieved 
locks are locks that got passed from another processor. 

The query obtained jrq Jocks returns a stack of obtained processor sets for a processor. A stack of sets 
models the way processors obtain locks: they go through a nested series of feature applications and each 
feature appUcation requires a set of locks before the feature can be executed. For each feature application 
the executing processor adds a new set on top of its stack. As soon as the feature application finished, the 
processor removes the top set from its stack. The query obtained -CS Jock returns the obtained call stack 
lock of a processor. Initially each processor starts with a lock on its own call stack and this call stack 
lock never changes. Thus this query is only declared for reasons of completeness. If a processor appears 
in a set of request queue locks, then the processor denotes its request queue lock. If a processor appears 
in a set of call stack locks, then the processor denotes its call stack lock. 

A processor can pass its locks to another processor. There are several queries to formahze this 
aspect. The features retrieved j-q Jocks and retrieved _cs Jocks return the retrieved locks of a processor. 
Both of these queries return a stack of sets. The stack keeps track of the set of retrieved locks for 
each feature application. These two stacks grow and shrink in parallel to the stack obtained^rq Jocks. 
Once a processor passed its locks, it caimot use them anymore until the locks are revoked. The query 
locks 4)assed returns whether a processor passed some or all of its locks or not. 

rqJocked: REG PROC ^ BOOLEAN 
k.rqJocked{p) require 
k.procs.has{p) 

csJocked: REG ^ PROC ^ BOOLEAN 
k.csJocked{p) require 
k. procs. has{p) 
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obtained rq locks: REG PROC ^ STACK [SET [PROC]] 
k. obtained. rq Jocks {p) require 
k.procs.has{p) 

obtained -cs Jock: REG PROC ^ PROC 
k. obtained. csJock{p) require 
k.procs.has{p) 

retrieved. rq Jocks: REG ^ PROC ^ STACK[SET[PROC]] 

k.retrieved-rq Jocks {p) require 
k.procs.has{p) 

retrieved. cs Jocks: REG ^ PROC ^ STACK [SET [PROC]] 
k.retrieved.csJocks{p) require 
k.procs.has{p) 

locks passed: REG PROC ^ BOOLEAN 

k. locks 4)assed{p) require 
k.procs.has{p) 

The following discussion first goes through the list of commands that add processors and commands 
that change the association of processors to objects. It then proceeds with the commands that handle 
locks. The command add^troc updates the regions with a new processor. Note that the processor must 
have been created beforehand. The axioms state that the new processor will be included in procs and that 
it will be stored in last. added 4)roc. The axioms also state how the new processor is initialized. The new 
processor's request queue is unlocked and its call stack is locked. Apart from the initial lock on the call 
stack there are no obtained or retrieved locks and hence the processor did not pass its locks. 

add proc: REG PROC ^ REG 

k.add4>roc{p) require 

-^k. procs. has {p) 
axioms 

k.add-proc{p) .procs. has{p) 

k. add _proc{p). last ^added^roc = p 

k.add.proc{p) .handle d.objs{p). is. empty 

-^k.add.proc{p) .rq .locked{p) 

k.add-proc{p) .csJocked{p) 

k.add.proc{p) .obtained. rq. locks (p) .is. empty 

k. add. proc{p). obtained. cs.lock{p) = p 

k. add proc{p). retrieved rq locks{p) .is empty 

k.add.proc{p).retrieved.csJocks{p).is.empty 

-^k.add.proc{p) .locks .passed{p) 

The command add-obj takes a processor p in procs and an object o that is not handled by a processor 
in procs yet. It returns the updated regions in which o is handled by p. 

add.obj : REG ^ PROC ^ OBJ ^ REG 
k.add.obj(p,o) require 
k. procs. has (p) 

Mq G k.procs, u G k. handled. objs{q) : u.id ^ o.id 
axioms 

k.add.obj{p, o) .handled. objs{p) .has{o) 
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In the opposite direction, the command remove obj removes an object that is handled by a processor 

in procs from the regions. 

remove _obj\ REG OBJ ^ REG 
k.remove-obj{o) require 

3/7 G k.procs: k.handledjobjs{p).has{o) 
axioms 

G k.procs: k. remove -obj{o). handled _objs{p). has (o) 

The following part discusses the commands that deal with the locking aspects of the regions. The 
command lock_rqs locks the request queues of a set of processors q on behalf of a processor p. None of 
these request queues must be locked beforehand. 

lockj-qs : REG PROC ^ SET[PROC] ^ REG 
k.lock.rqs{p,l) require 

k.procs. has{p) 

Vx G / : k.procs. has{x) 

\/x &l: ^k.rqJocked{x) 
axioms 

k.lock _rqs (pj). obtained j-q Jocks (p) = k. obtained j-q Jocks {p) .push (/ ) 
Vx G /: k.lock-rqs{p,l).rqJocked{x) 

At some point, processor p will not require the obtained request queue locks anymore because p made 
sure to enqueue all necessary features requests. Processor p uses the command pop -obtainedjrq Jocks to 
remove his claims on the obtained request queue locks. This requires that processor p is in possession of 
these locks, i.e., that p did not pass its locks. 

pop obtained rq locks: REG PROC REG 
k. pop. obtained. rq Jocks {p) require 
k.procs. has {p) 

^k. obtained. rq Jocks {p). is. empty 
-^k.locks.passed{p) 
axioms 

k. pop. obtained. rq.locks{p). obtained. rq.locks{p) = k. obtained. rq.locks{p). pop 

Removing the locks from p's, obtained request queue locks stack does not mean that these request 
queues are unlocked. It just means that the request queue locks are not claimed by p anymore and 
therefore p will not enqueue further feature requests on the respective processors. The request queues 
remain locked until they get unlocked with a call to the command unlock.rq. This happens after the 
processors whose request queues got locked by p finished all the requested feature applications. The 
precondition of the command states that a request queue can only be unlocked if it is not claimed by any 
other processor. This precondition guarantees that the request queue can only be unlocked when it is 
not used as an obtained or retrieved lock by any other processor anymore. Note that there is no unlock 
command for call stack locks because the call stack never gets unlocked. 

unlock_rq: REG PROC ^ REG 
k.unlock.rq{p) require 
k.procs. has (p) 
k.rq.locked{p) 

Mq G k.procs: -^k. obtained. rq Jocks (q). flat. has (p) 
axioms 

-^k. unlock. rq{p) .rqJocked{p) 
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The request queues remain locked until explicitly unlocked with a call to unlockjrq. Between the 
call to pop. obtained. rq Jocks and the call to unlock j-q, the owner of these locks is undefined. In some 
situations this is not satisfactory. A different solution must be found if another processor wants to claim 
the locks until they are unlocked. The command delegate. obtained. rq Jocks serves this purpose. It takes 
a processor p and a number of processors I and makes p the owner of the request queue locks of all 
processors in I by adding these locks to the obtained request queue locks stack of p. This can only work 
if there is no current owner and the request queues are indeed locked. 

delegate. obtained. rq. locks: REG PROC ^ SET[PROC] REG 
k. delegate obtained rq locks {p ~l) require 
k.procs.has{p) 

Vx € / : k.procs.has{x) 

\/x £l: -'By G k.procs: k.obtained-rqJocks{y) fiat .has{x) 
\/x &l: k.rq. locked {x) 
axioms 

k. delegate. obtained j-qJocks{p, I) .obtained. rq Jocks (p) = k. obtained. rq Jocks (p) .pushQ.) 

Delegation is different from lock passing: delegation is the permanent transfer of ownership and lock 
passing is the temporary transfer of the right to use the locks. The following discussion looks at the 
commands to pass and revoke locks. The command pass Jocks takes a processor p and a processor q as 
well as a set of request queue locks Ir along with a set of call stack locks 4. The result is an updated 
instance of REG in which Ir and Ic have been passed from p to q. As a precondition for this task, 
processor p must be in possession of all these locks. This means that all the locks in Ir and 1^ must be 
obtained or retrieved locks of p and the locks must not be passed. The updated result must reflect that 
some or all of p's locks have been passed. However, because the two sets of locks can potentially be 
empty, p\ locks must only be marked as passed if at least one of the two sets of locks is non-empty. 
Lastly, the command must take care of one special case of the lock passing operation. If a processor q 
different from processor p passed its locks in a previous lock passing operation and now the command 
passes these locks back to q, then the command has to mark the locks of processor q as not passed. This 
case is important to handle separate callbacks. 

pass Jocks: REG ^ PROC ^ PROC ^ TUPLE [SET [PROC], SET [PROC]] ^ REG 
k. pass Jocks {p,q, (IrJc)) require 
k.procs. has{p) A k.procs. has [q) 
\/x£ Ir: k.procs. has{x) A Vx G : k.procs. has{x) 

Mx&lr: k. obtained. rq. locks (p). flat. has (x) V k. retrieved .rq Jocks (p). flat. has {x) 
\/x E Ic: X = k.obtained csJock{p) V k.retrieved cs Jocks (p) .flat.has(x) 
-^k. locks ^assed{p) 



axioms 



k.passJocks{p,q,{lr,lc)) -locks jpassed{p) = ^ 





k.locks.passed{q)f\ 




k-obtained-cs Jock{q) G lc/\ 
\ k. retrieved. cs Jocks (q). flat C. Ic J 
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The command revoke Jocks takes a processor p and a processor q. It reverses the effect of a lock 
passing operation from a processor pioq and returns an updated instance of REG. This is only allowed if 
processor p passed locks to ^ in a preceding lock passing operation. Note that the lock passing operation 
from pXo q potentially marked the locks of q as not passed. Revoking the locks from qXo p requires 
the reverse action. If p has retrieved locks in common with the locks of q, even after the retrieved locks 
from p have been removed from q, then ^'s locks must be marked as passed because they are now in 
possession of p. 

revoke docks: REG ^ PROC ^ PROC ^ REG 
k. revoke Jocks {p,q) require 

k.procs.has{p) Ak.procs.has{q) 

^k. retrieved _rq Jocks (q). is _empty A -^k.retrieved_csJocks{q) .is^empty 
k.retrievedjrq Jocks {q). top C k.obtainedjrqJocks{p).flatiJk.retrievedjrqJocks{p).flat 
k.retrievedjcs Jocks{q) .top C {k.obtainedjcs Jock{p)}Uk. retrieved. as Jocks (p). flat 
k.retrieved.rqJocks{q).top\Jk.retrieved-CsJocks{q).top 7^ {} — > k.locks-passed{p) 
-^k. locks -passed{q) 
axioms 

-^k. revoke locks {p, q) .locks passed{p) 

k. revoke Jocks {p,q) .retrieved _rqJocks{q) = k.retrieved_rqJocks{q) .pop 
k. revoke Jocks {p,q) .retrieved.es Jocks{q) = k. retrieved.es Jocks {q) .pop 



( pi-qK 

/ 3x E k. retrieved j-q Jocks (p). flat: ( 

k. obtained _rq Jocks (q) .flat.has{x) V 
k.retrievedj-qJocks{q).pop.flat.has{x) 



\ 



\ 



V 



3x G k. retrieved jcs Jocks (p). flat: ( 

X = k. obtained -CsJock{q)\/ 
k. retrieved. cs Jocks (q). pop. flat. has (x) 

V) 

— > k.revoke locks{p, q) .locks ^assed{q) 

These commands wrap up the mapping of processors to objects and the locking aspects. The dis- 
cussion continues with a number of auxiliary queries to simplify access to the presented queries. The 

command add.obj makes sure that a processor is assigned to each object that gets added. This mapping 
is available through the query handled-objs. Thus it is possible to define an auxiliary query handler that 
is inverse to the query handled. objs. 

handler: REG ^ OBJ ^ PROC 
k.handler[o) require 

3/7 G k.procs: k. handled. objs{p). has (o) 
axioms 

k.handled.objs{k.handler{p) ) .has{o) 

There are four different categories of locks that each processor can have. For both the request queue 
locks and the call stack locks, there are queries for obtained and retrieved locks. In some situations it 
is easier to just work with request queue locks and call stack locks without splitting them into obtained 
and retrieved locks. The auxiliary queries rq Jocks and csJocks serve this purpose. The auxiUary query 
rq Jocks returns a set that contains all the obtained and the retrieved request queue locks of a processor 
p. Similarly, the auxiliary query cs. locks returns all the call stack locks of a processor p. 
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rq Jocks : REG ^ PROC ^ SET[PROC] 
k.rqJocks{p) require 

k.procs.has{p) 
axioms 

k.rq_locks{p) = k.obtained.rqJocks{p) flatU k.retrieved.rqJocks{p) flat 

cs Jocks: REG ^ PROC ^ SET [PROC] 
k.csJocks(p) require 

k.procs.has{p) 
axioms 

k.csJocks{p) = {k.obtained.cs Jock{p)} U k.retrieved.cs Jocks{p) flat 
5.4.3 Creation 

The constructor make creates a new instance of REG. The new instance has no processors. 

make: REG 
axioms 

make .pwcs. is. empty 

5.5 Store ADT 

Each processor in the system has a call stack to execute features. Every time a processor executes a 
feature, a new call stack frame gets created on top of the call stack. The new call stack frame stores the 
values of formal arguments, local variables, the current object entity, and the result entity for the current 
feature execution. The call stack is also responsible for the order of feature executions on the same pro- 
cessor This formalization separates the two concerns of the call stack. The store only models the values 
in each stack frame. A store has a stack of environments for each processor, where each environment 
maps names to values. This section first presents an ADT for environments and then presents an ADT 
for the store. 

5.5.1 Environments 

The ADT ENV has a query names that stores all the defined names. The query val can then be used to 
get the value for each such name. 

names: ENV ^ SET [NAME] 

val : ENV -> NAME ^ REF U PROC 
e.val{n) require 
e. names. has{n) 

The command update takes a name and a value and returns an updated environment. Note that it does 
not matter whether the name is already defined in the environment or not. In any case, the name will be 
defined in the updated environment and the name will be mapped to the value. The value can either be a 
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reference or a processor. Environments with processor values are not strictly needed to describe SCOOP, 
however they make it possible to have a unified view on attribute values and environment values. 

update : ENV ^ NAME ^ REF U PROC ^ ENV 
axioms 

e.update{n,v). names = e.names(J{n} 
e . update (n , v) . val (n) = v 

The constructor make returns an empty environment. 

make: ENV 
axioms 

make .names . is empty 

5.5.2 Mapping from processors to enviromnents 

The ADT STORE has a single query envs that stores a stack of environments for each processor. 
envs: STORE ^ PROC ^ STACK[ENV] 

The command push.env pushes a given environment on top a processor's stack of environments. The 
command pop env pops the top environment from a non-empty stack of environments. 

push.env : STORE ^ PROC ^ ENV ^ STORE 
axioms 

s.push.env{p,e).envs{p) = s.envs{p).push{e) 

pop^env : STORE ^ PROC ^ STORE 
s.pop.env{p) require 

^s.envs{p). is -empty 
axioms 

s.pop-env{p).envs{p) = s.envs{p).pop 
The constructor make creates an empty store. 

make: STORE 
axioms 

yp G PROC: make. envs (p). is uempty 
5.6 State ADT 

The ADT STATE models the state with three queries to retrieve the different parts of the ADT. 
regions: STATE REG 

heap : STATE ^ HEAP 

store: STATE ^ STORE 
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The command set sets the regions, the heap, and the store at the same time. A precondition specifies 
consistency criteria between the parts of the state. The first two precondition clauses state that a processor 
can handle an object if and only if the object is on the heap. The third precondition clause states that if the 
heap declares a feature as non-fresh on a processor p, then the regions must know about this processor. 
The fourth precondition clause requires that all processors stored in attribute values are known by the 
regions. Note that HEAP already requires that the references stored in attribute values are known. The 
fifth precondition clause states that each non-empty environment in the store must belong to a processor 
that is known by the regions. The sixth precondition clause states that each value in the store must either 
be a known reference or a known processor. 

set: STATE ^ REG ^ HEAP ^ STORE ^ STATE 

<7.set{k,h,s) require 

G k.procs,o € k.handled_ohjs(p) : h.ohjs.has{o) 
Mo G h.objs: 3p G k.procs: o G k. handled -objs{p) 
yp e PROC,/ G FEATURE: -^h.is J^esh{p J) k.procs. has{p) 
Vo G h.objs, a G o. class Jype. attributes: 

o.att-val{a) G PROC — k.procs. has{o.att-val{a)) 
yp G PROC,e G s.envs{p) : ^e. names. is jempty — > k.procs. has {p) 
Vp G k.procs, e G s.envs{p),x G e.names: 

{e.val{x) G REF — )■ e.val{x) = void V h.refs. has {e.val{x)))/\ 

{e.val{x) G PROC — >■ k.procs.has{e.val(x))) 
axioms 

G.set{k,h,s). regions = k 
<y.set(k,h,s).heap = h 
o .set{k,h,s). store = s 

5.6.1 Creation 

To create a state, one has to create the three parts of the state. This is done with the constructor make. 

make: STATE 
axioms 

make.regions = new 'REG.make 
make.heap = new HEAP.maA:e 
make. store = new STORE. maA:e 

5.6.2 Facade 

It is too cumbersome to work with STATE as it is. For example, the following expres- 

def 

sion defines a new state a' in which a new processor has been added to the state a: a' = 
a .set {(J .regions .add 4)roc {new PROC.make) , o.heap, o. store). This expression is too long for this sim- 
ple task, especially if the expression is used multiple times. It would be easier to have an auxiliary 
command that does this job for us. The facade is an abstraction with auxiliary features that provide easy 
access to the state functionality. The facade is divided into different aspects. The following discussion 
dedicates one section to each aspect. It starts with the mapping of processors to objects and the mapping 
of references to objects. It continues with a section on how to set values, followed by a section on how 
to get values. It concludes with a section on locking. 
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5.6.3 Mapping of processors to objects and mapping of references to objects 

The regions and the heap manage the references, the objects, the processors, and the mapping between 
them. The facade unifies all related features in one aspect. This section first defines a number of auxiliary 
queries for the mapping of processors to objects. Next, it defines auxiliary queries for the mapping of 
references to objects. It then defines auxiliary commands that work on both aspects. 

The two auxiliary queries procs and lastjodded-proc give access to all the processors and the last 
added processor. 

procs: STATE ^ SET [PROC] 
axioms 

c. procs = c .regions .procs 

lastjadded^roc: STATE ^ PROC 
a. last added jproc require 

-1 (7 . regions .procs . is jempty 
axioms 

o.lastjadded^roc = o .regions .last .added ^roc 

The auxiliary query handler gives the handler of an object referenced by r. The auxiliary query 
uses the heap to get the referenced object and then gives this object to the regions to get the handler. In 
contrast to the corresponding auxiliary query in REG, the version here takes a reference instead of an 
object. The version in REG deals directly with objects rather than references because it does not know 
about the heap and thus the mapping from references to objects is not available. The facade, however, 
has access to both the regions and the heap and thus it can use the preferred way of identifying objects: 
references. 

handler: STATE REF ^ PROC 
o.handler{r) require 
(J.heap.refs.has{r) 
axioms 

o .handlerir) = a. regions. handler {o. heap. ref.obj{r)) 

The auxiliary query new^roc is a shorthand for processor creation. The auxiliary query 
lastjadded.obj returns the object that has been added last to the heap. The auxiliary query ref.obj 
returns the object that is associated to a given reference. In the other direction, the auxiliary query ref 
returns the reference to a given object. The auxiliary query new^obj is a shorthand for object creation; it 
returns a new object with a given class type. 

new4>roc: STATE PROC 
axioms 

o.new-proc = new PROC. make 

lastjadded obj : STATE OBJ 
o. last. added. obj require 
-^a.heap.objs.isuempty 
axioms 

o.lastjadded-obj = o .heap. last jadded-obj 
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ref_ohj : STATE ^ REF ^ OBJ 
o.ref-obj{r) require 
G. heap. refs. has (r) 
axioms 

c .ref jobj{r) = a.heap.refjobj{r) 

ref : STATE ^ OBJ ^ REF 
o.ref{o) require 

o .heap.objs.has{o) 
axioms 

O.ref{o) = o .heap .ref {o) 

new^obj: STATE ^ CLASS TYPE ^ OBJ 
axioms 

G.newjobj{c) = new OBJ.make{c) 

The discussion continues with the auxiliary commands that modify the mapping of processors to 
objects and the mapping of references to objects. Before an object can be added to the set of handled ob- 
jects of a processor, the processor must exist. If the processor does not exist yet, the command add.proc 
can be used to update a state with a new processor. 

add proc: STATE ^ PROC ^ STATE 

o .add_proc{p) require 

-1 o . regions .procs .has (p) 
axioms 

c .add^roc{p) = c .set{a .regions.add^roc{p),c .heap, o .store) 

The auxiliary command addjobj can then be used to add an object to the processor and the heap. The 
auxiliary command takes a processor p and an object o and it returns a state in which object o is part of 
the heap and handled by processor p. 

add.obj: STATE ^ PROC ^ OBJ ^ STATE 

(j.add-obj{p,o) require 

(7 . regions .procs. has{p) 

Vm G o.heap.objs: u.id / o.id 

Va G o. class Jype. attributes: 

{o.att_val{a) G REF — )■ o.att_val{a) = voidy G .heap. ref s.has{o.attJval{a)))f\ 

{o.att-val{a) G PROC o .regions. procs. has{o.att-val{a))) 
axioms 

G.addjobj{p,o) = c .set{c .regions. add jobj{p,o), G. heap. add. obj{o),G. store) 

The auxiliary command update .ref updates a reference with an updated object. It takes a reference 
r on the heap and an object o and it returns a state in which o replaced the object u referenced by r on 

the heap and in the regions. Note that o must indeed be an updated version of the object referenced by 
r. The auxiliary command first removes u from the set of handled objects and then adds o to the set of 
handled objects of m's handler. Then it updates the heap with the command update^ref, which is declared 
in HEAP. 
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update_ref : STATE REF ^ OBJ ^ STATE 
a. update -ref{r,o) require 
(J.heap.refs.has{r) 
odd = o .heap .ref jobj{r) .id 
\/a E o. class Jype. attributes: 

{o.att_val{a) G REF — )• o.att_val{a) = void y o .heap. ref s.has{o.att_val{a)))/\ 
[o .att -val{a) G PROC — )■ o .regions. procs.has{o.att-val{a))) 
axioms 

O. update _ref{r,o) = (J.set{k,h,s) 
where 

M o .heap .ref jobj{r) 
def 

k = o. regions. remove -obj{u).add-obj{o. regions. handler{u),o) 
h ^= o. heap. update -ref {r,o) 

def 

s = o. Store 



5.6.4 Setting values 

This section takes a look at how to set values. To start, it looks at a prerequisite for this task: the deep 
import operation. Setting values includes setting values of formal arguments, values of local variables, 
the value of the current object entity, the value of the result entity, and attribute values of the current 
object. All of these values can be written and read without a feature call. This section concludes with 
auxiliary commands to set the status of once routines. The SCOOP validity rules exclude other types of 
value setting operations. 

Deep import operation Expanded objects have a copy semantics: if an object o of expanded class 
type is the source of an attachment, then a copy u gets attached to the destination of the attachment. 
However, a shallow copy is not sufficient if o's handler p is different from m's handler q. If o has an 
attached non-separate entity, then u now has a non-separate entity to which a separate object is attached. 
This would result in a traitor - a non-separate entity that points to a separate object. The SCOOP model, 
as defined by Nienaltowski f25l, introduces the import operation to solve this issue. Applied to o the 
import operation creates a copied object structure that mirrors the original object structure in a way that 
o and all the objects reachable from o through non-separate references are replaced with copied objects 
that are handled by q. This data structure then gets attached to the destination of the attachment. The 
import operation computes the non-separate version of an object structure. 

Clarification 2 (Deep import operation). The import operation potentially results in a copied object 
structure that contains both copied and original objects. This can be an issue in case one of the copied 



objects has an invariant over the identities of objects, as shown in example 5.6.4 



Example 3 ( Invariant violation as a result of the import operation ). Imagine two objects x and y handled 
by one processor and another object z. handled by another processor. Object x has a separate entity a that 
points to z and a non-separate entity b that points to y. Object z has a separate entity c that points to y. 
Object X has an invariant with a query a.c = b. An import operation on x executed by a third processor 
will result in two new objects x' and y' on the third processor. The reference a of object x' will point to 
the original z- The reference b of object x' will point to the new object y'. This situation is illustrated in 
Figure[2] Now object x' is inconsistent, because a.c and b identify different objects, namely y and /. □ 
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Figure 2: Invariant violation as a result of the import operation 



The deep import operation is a variant of the import operation that does not mix the copied and the 
original objects. □ 

Instead of copying only the objects that are reachable through non-separate references, the deep 
import operation makes a full copy of the object structure. The deep importing processor handles all the 
copies of the objects that are non-separate with respect to the object to be imported. Each other separate 
object is handled by the processor of the respective original object. The deep import operation does not 
show the issue with invariants. The drawback of the deep import operation is that more objects must be 
copied. Nevertheless, we use the deep import operation in our formalization because we cannot tolerate 
violated invariants. Once routines complicate the deep import operation a bit. Consider a processor p 
that wants to deep import an object o handled by a different processor q. For each non-separate once 
function / of each copied object the following must be done: if a non-separate once function / is fresh 
on p and non-fresh on q, then / must be marked as non-fresh on p and the value of / on g must be used 
as the value of / on p. If a once procedure / is fresh on p and non- fresh on q, then / must be marked as 
non-fresh on p. In all other cases, nothing must be done. 

The auxiliary command deepJmport implements the deep import operation. The command takes an 
importing processor p and a reference r to be imported. The command returns a state in which the copied 
object structure exists on the heap and the objects are associated to the respective processors. The copied 
object structure is accessible through the auxiliary query lastJmportedj-ef. 

deep Import: STATE ^ PROC ^ REF ^ STATE 
<j.deepJmport{p,r) require 
<J. regions. procs.has{p) 
o .heap .refs .has {r) 
axioms 

(J.deepJmport{p,r) = a' 
(J. deep Jmport{p,r). last .imported -ref = r 
where 

w '= new MAP[REF, REF] .make 

(r',w',a') deepJmport_rec-with_map{p,a.handler{r),r,w,o) 



last -imported -ref : STATE — t- REF 
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The auxiliary command deep .import is based on deep Import j-ec. with jnap. This auxiliary function 
takes a tuple containing an importing processor p, a processor q that handles the root of the object 
structure to be imported, a reference r to be deep imported, and a state a to be modified. Note that 
the object referenced by r is not necessarily handled by q because this object might be on a different 
processor than the handler of the root of the object structure to be deep imported. The function returns 
another tuple with a reference r" to the copied object structure and an updated state c" . 

deepJmport.rec.withjnap{p,q,r,w,o) = {r",w",o") 



The auxiliary function deep Import jrecswithjuap works hand in hand with the auxiliary function 
deep Import jrec ^without jnap. They have the same signature and together they recursively traverse the 
object structure and make a deep copy of it. The functions must ensure that no object gets copied twice. 
For this purpose the functions take as an additional argument a map w that maps references to objects 
in the input data structure to references in the copied data structure. A mapping from one reference x to 
another reference y means that the object referenced by y is the copy of the object referenced by x. An 
updated map is returned as part of the result tuple. The auxiliary command deeplmport starts the recur- 
sion with an empty map. The auxiliary function deep Import -rec -with jnap uses the map to determine 
whether the object referenced by r has already been copied. In such a case, the result of the function 
comes from the map. Otherwise the auxiliary function deep Import _rec_withjnap returns the result of the 
auxiliary function deeplmport jrecjwithoutjtiap. The auxiliary function deeplmport jrec-withoutjnap 
creates a copy of the object referenced by r and handles once routines. Finally, it returns a new reference 
r', an updated map W in which r is mapped to r', and an updated state a' . 

The auxiliary function deep Import _rec_withoutjnap is divided into several steps: a copy step, an 
attribute values update step, a clients update step, a once status update step, and a result generation 
step. Each of the steps has several definitions associated to it and each set of definitions depends on 
the definitions of the previous step. The following discussion goes through each of these steps in more 
details. 

The copy step includes the definitions of o, Oq, o[) and w[y The definition o is the object referenced 
by r, and the definition o'q makes a copy of o. In the next step, the function defines an updated state o'q 
that includes the copy o'q. There are two cases to be differentiated at this point. If o is handled by q, then 
o'q must be handled by p. Otherwise o'q must be handled by the handler of o. The definition Wq is the 
updated map. 

The attribute values update step recursively uses deep Import jrec-withjnap to import all the non- 
void reference attribute values of o using the updated map. This leads to an updated object with the 
deep imported values. This step includes the definition of {ai, . . . ,a„}, as well as the definitions of 
{r'j, . . . ,r',}, {wj, . . . ,^^1, {a[, . . . , a,'}, and {o^, . . . ,o'j}. The set {ai, . . contains each attributes 
of o whose value is a non-void reference. The function defines (r^, w-, a/) for / = 1 . . .n as a sequence 
of tuples. Each of the tuples is responsible for a single recursive deep import operation for one of the 
attributes in {ai, . . . ,a„}. Each such operation results in an updated map and an updated state that must 
be used in the next deep import operation. The result of this is an updated map w'j, and updated state 
o'^, and references ri , . . . , r„ to deep imported data structures. Finally, the function defines a sequence of 
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updated objects {o[,. . • that ends with the updated object o'^. The updated object has the values of 
the attributes {ai , . . . , a„} set to the deep imported data structures referenced by ri , . . . , r„. 

Until now, the function has an updated state (7^ that contains the initial copy Oq. In the client update 
step, the function updates a'^ such that the reference to o'q points to the updated object oj,. This is done 
in the clients update step. This step includes the definition a^. Note that is derived from the state Gq, 
which includes the object Oq. 

deep Jmport^rec. without jnap{p, q, r, w, o) = {r',w', o') 
where 

o ^= O .ref -obj{r) 

Oq = o.copy 



J def ( G.add.obj{p,o'Q) if a. handler (r) = q 

(7. add -obj {(J. handler (r) , o'q) otherwise 



w'q ^= w.add{r, aQ.ref{oQ)) 

def 

{a\, . . . ,a„} = {a \ o.att_val{a) G REF A o.a»_va/(a) / void} 

V/ G {!,...,«}: {r\,w\,(y'j) deepJmport.rec-with-map{p,q,o.att-val{ai),w'i_i,ol_i) 
Vi G { 1 ,...,«} : o'{^= o\_ 1 .set_att_val{ai, r-) 
(^x =^ K-'^pdate.ref{a^.ref{o'Q),o'„) 

set-onceJuncJiotJ'resh{(j!^.handler{a!^.ref{o'f^)) , f\ , o'^.once-result{o'^.handler{r) , /i )) 

set-onceJuncjiotJ'resh{G[.handler{o[.ref{o[^ )),fw, o'^.once-result{a'^.handler{r) ,fw)) 
set-once4>rocjiotjresh{(j!^.handler{o!^.ref{o'„)), f^+i ) 

.setjonce^rocjiotJresh{c'^.handler{a'^.ref{o'^)), fm) 
where 

^ ^{x G o. class Jype. functions \ X. is. once A 3c, d: Fhx: (<i,»,c)A 
{fi,---,fw} = c'^.isJresh{o'^.handler{o'^.ref{o'^)),x)A 

-^o'j^.is afresh ( o'^ . handler ( , x) } 
^ ^ {x G o. class Jype. procedures \ x.isjonce/\ 
{fw+\,---Jm} = o'^.isJresh{o'^.handler{o'^.ref{o'n)),x)A 



r = a ref{o„) 



^G'^.isJresh{G^.handler{r),x)} 



y 

I def , 

W 

a = Cy 



In a next step, the function takes care of the once routines of the imported object. For this, it defines a 

new state o[. based on the state a'. It defines {f\ , . . . as the set of all non-separate once functions of 
o that are fresh on the processor a^.handler{a^.ref{o'^)), which handles the copied object, but non-fresh 
on the processor a^.handler{r), which handles the object referenced by r. Note that the two processor 
can be the same, in which case the set {fi,...,fw} is empty. Similarly, it defines the set {fw+i ,---,fm} 
for once procedures. For each once routine defined in this way, it updates the state (7^ such that the 
once status is taken over to the handler of the copied object. These definitions deal with the case where 
a once routine is fresh on the handler of the copied object, but non-fresh on the handler of the object 
referenced by r. Note that the remaining cases are implicitly taken care of because no change to the state 
is necessary. The result is the state Oy. 
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The last step defines the result of the function, based on the definitions of the preceding steps. The 
result generation step defines the resulting reference / to the imported object o'^, the resulting map w', 
and the resulting state a' . 

Setting values of formal arguments and the value of the current object entity The deep import 
operation is used in two ways. It is used when an expanded object handled by one processor gets used 
as an actual argument for a formal argument on another processor. The deep import operation also gets 
used when an expanded object handled by one processor gets returned to another processor. This section 
focuses on the argument passing aspect. 

The auxiliary command push_env_with_feature defines a state in which a processor p receives a new 
environment. The new environment is initialized for the execution of the feature / with target reference 
ro and actual argument references (ri , . . . , r„). Actual arguments of expanded type must either be copied 
or they must be deep imported. 

push_env_with_feature : STATE PROC ^ FEATURE REF ^ TUPLE ^ STATE 

<j .push_env-with_feature{p , f , ro, (ri , . . . , r„)) require 
O. regions. procs.has{p) 
f .formals. count = n 

V/ E {0, . . . ,«} : r, 7^ void — )• o .heap .refs .has {ri) 
axioms 

a.push_env-withj'eature{p,f, ro, (ri , . . . , r„)) = 

o'^. set {ol^. regions, o'^.heap, (J^.store.push.env{p,e)) 
where 

V/G{1,. ..,«}: {a[y^'^ 

if 3d, q,c: F h f.formals{i) : {d, q, c) Ac.is_exp A r,- / void A o'i_i.handler{ri) 7^ p 
{Ox, Ox-last -imported -ref) 
where 

Ox = Oj_i.deep_import[p,ri) 
^ if 3d, q,c: F h f.formals{i) : (d, q, c) Ac.is.exp A r,- 7^ void A o'_i. handler (rj) = p 
{Ox, Ox .ref {Ox -last .added _obj)) 
where 

Ox o-_i.add-obj{p, Oj_i. heap. ref -obj{ri). copy) 
otherwise 

def 

w = new ENV.maA:e 

.update (f. formals (l). name, r[) ... .update {f. formals (n). name, r[^) 
.update{f .locals{\) .name, void) . . . .update{f .locals{f .locals. count). name, void) 
.update {Current, ro) 
def { w //■/ G PROCEDURE 

^ ~ \ w.update{Kesn\i,void) /f/ G FUNCTION 

In a first step, the auxiliary command defines an updated state, in which p gets a new initialized 
environment e. The updated state is based on an intermediate state o'„, which gets defined in a cascade 
of state updates with the goal of either copying or deep importing the actual arguments of expanded 
type. The cascade starts with the definition of a starting state Oq. For each formal argument, the cascade 
defines a tuple {o-,r'i) with an updated state and a reference. If the corresponding actual argument is 
of reference class type, nothing needs to be done. If the actual argument is of expanded class type and 
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the referenced object is not handled by p, then p must deep import the object structure. This results 
in an updated state and a new reference to the deep imported object structure. If the actual argument 
is of expanded class type and the referenced object is handled by p, then the expanded object must be 
copied. This results in an updated state and a new reference to the copy. The resulting state o'^ contains 
all the deep imported and copied objects. The resulting references /j, . . . will be used for values of 
the formal argument names. 

In a next step, the command defines the environment w as a new environment that gets updated to 
map formal argument names, local variable names, the current entity name, and the result entity name to 
the respective values. The names of the formal arguments get mapped to the references /j , . . . , r^. Names 
of local variables are mapped to the void reference. The current entity name is mapped to the target 
reference. 

The environment w is the final environment e in which the result name gets mapped to the void 
reference. This environment and the updated state define the result of the command. The auxiliary 
command push env pushes e onto p\ stack of environments. The auxiliary command push env takes a 
processor p and an environment e. It returns a state in which e is pushed on top of p\ environment stack. 

push.env : STATE ^ PROC ^ ENV ^ STATE 
(j.push-env{p,e) require 
(J. regions. procs. has (p) 
axioms 

<J.push_env(p,e) = G. set (o. regions, cheap, o. store. push_env{p,e)) 

The effect of a call to push ^env^with feature or a call to push_env can be undone with a call to 
the auxiliary command pop.env. This auxiliary command takes a processor p and removes the top 
environment from p's stack of environments. 

pop-env : STATE ^ PROC ^ STATE 
a.pop.env{p) require 
c . regions .procs. has (p) 
-^a .store. envs{p) .is empty 
axioms 

G. pop env {p) = G.set{G. regions, G. heap, G. store. pop -env{p)) 

Setting values of local variables and the value of the result entity The values of local variables and 
the value of the result entity are maintained in the store. The auxiliary command set.envjval sets a value 
V for the name n in processor /j's top environment. For this, it defines an updated environment e in which 
n is set to v. It then defines an updated store s by first removing the top environment and then adding 
the updated environment e. The updated store is then used to define an updated state. The updated state 
becomes the result of the auxiliary command. 
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set-env.val: STATE PROC ^ NAME ^ REFUPROC ^ STATE 

a.set.em.val{p,n,v) require 
(7 . regions .procs.has{p) 
-^G .store .envs[p) .is ^empty 

V G REF A V / vo/J — )• o. heap. refs. has {v) 

V G PROC — > c .regions. procs. has iy) 
axioms 

(7.5ef_env_va/(;7,n, v) = G.set{k,h,s) 
wliere 

e a .store .envs{p) .top .update{n,v) 
k = o. regions 
h cheap 

s ^= G .store .pop -env{p) .push -env{p ,e) 

Setting attribute values of tlie current object The auxiliary command setjatt.val takes an object o, 
a name n, and a value v. It returns an updated state in which the attribute with name n of object o is set 
to the value v. In a first step, the auxiliary command defines an updated object with a call to setMttJval. 
This updated object is then used to update the existing reference to o in the state. 

set att val: STATE OBJ ^ NAME ^ REFUPROC ^ STATE 

<7.setMtt_val{o,n,v) require 
o. heap. objs. has (o) 

3a G o. class Jype. attributes: a.name = n 

V G REF A V 7^ void — t- <j. heap. refs. has (y) 

V G PROC — > o. regions. procs. has (v) 
axioms 

G.setMtt-val{o, n, v) = c .update ref {a .heap. ref{o) , o.setjatt-val{a, v)) 
where 

a ^= o. class Jype. feature Jjyjiame{n) 

Setting values of local variables, the value of the result entity, and attribute values of the current 
object in a unified way The auxiliary command set_val attaches a value v to an entity with name n. 
The entity can either be a local variable or the result entity in the top environment of p. It can also be an 
attribute of the current object on p. In either case, the update affects an entity on p. 

The definition of the resulting state is based on the auxihary definitions o, a' , and v' . The definition 
o defines the current object, as defined by the top environment of processor p. The precondition makes 
sure that there is always such an environment on p where the current object is defined. If v is a reference 
and the referenced object is an object of reference class type, then v can be attached directly to the entity 
with name n. If the object is an expanded object handled by processor p, then the referenced object 
must first be copied. Expanded objects handled by a processor different than p must be deep imported. 
However, this is done right when the object gets returned from another processor to p. The definitions 
a' and v' define a state and a value that are potentially updated according to these rules. 

The state o' must be updated with the value v' . The update can either affect the current object on p 
or it can affect the top environment of p. Attribute names of the current object, local variable names, and 
formal argument names are distinct. Therefore it is safe to first check whether the current object o has 
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an attribute with name n, in which case the current object gets updated with a v'. If the current object 
does not have such an attribute, then it is safe to assume that the top environment contains an entity with 
name n, in which case the top environment gets updated. 

set^val : STATE ^ PROC ^ NAME ^ REF U PROC ^ STATE 

a.set_val{p,n,v) require 
O. regions. procs.has{p) 

.store .envs{p) .is _empty A o .store .envs{p) .top .names .has {Current) 

V G REF A V 7^ void — )• o .heap .refs .has{v) 

V G PROC — )• o .regions. procs. has [v) 
axioms 

if3a G o. class _type. attributes: a.name = n 

(j'.setjattJval{o,n,v') 
otherwise 

<j' .set_env_val{p,n,v') 



(J.set-val{p,n,v) = < 



where 

def 

o = o .heap. ref -obj{o .Store. envs{p). top. val{Qurreni)) 

(a ,y ) = 

ifv G REF A V / void A O .heap .ref -obj{v) .class Jype .is ^exp A o .handler(y) = p 
(a^, Ox-ref {Ox- last .added -obj)) 
wliere 

def 

Ox = o .add-obj{p,o .heap.ref -obj{v).copy) 
otherwise 
{o,v) 



Setting values of once functions Values can also be stored in the status of once functions. A once 
function can be fresh or non-fresh. If the once function is non-fresh on a processor p, then there is a once 
result for the once function on p. A once function is set as non-fresh during the execution of the once 
function. The following discussion takes a look at how a processor can set the status of once routines in 
general, i.e., it considers both once functions and once procedures. 

The auxiliary command set^ncej'uncjiotj'resh takes a processor p, a once function /, and a value 
r. It returns an updated state in which / is set as non-fresh with the once result r. If / is declared as 
non-separate, then / is set as non-fresh on p with the once result r. If / is declared as separate with or 
without an explicit processor specification, then / is set as non-fresh on all processors. 

set _once_funcjiot afresh : STATE PROC ^ FEATURE ^ REF ^ STATE 
(J.set.onceJuncjiotJ'resh{p,f, r) require 

o .regions. procs. has{p) 

f G FUNCTION A /./5_o«ce 

r 7^ void — ?■ CJ. heap. refs. has (r) 
axioms 

(j.set_once_funcjiot_fresh{p,f,r) = 

(j.set{<J. regions, <J. heap. set -oncc-func -not -fresh(p,f, r),<J. store) 

The auxiliary command set _once 4)roc jiot _fresh does the same for once procedures. It takes a pro- 
cessor p and a once procedure / and it returns a state in which / is set as non-fresh on p. 
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set _once4)rocjiot .fresh : STATE PROC FEATURE STATE 
a.setjonce-procjiotj'resh(p,f) require 
a . regions .procs.has {p ) 
/ G PROCEDURE A f is. once 
axioms 

O .set-once4>rocJT.ot-fresh{p,f) = 

(J .set((J .regions , a.heap.set_once4>rocJiotJresh{p,f),a.store) 

5.6.5 Getting values 

This section takes a look at how a processor can read a value that got written with one of the mechanisms 
from Section U.6.4[ 

Getting values of formal arguments, the value of the current object entity, values of local variables, 
and the value of the result entity The auxiliary query envs takes a processor p and returns the stack of 
environments for p. The auxiliary query env_val is more specialized. It takes a processor p and a name 
n and it returns the value stored under n in the top environment of p. 

envs : STATE ^ PROC ^ STACK [ENV] 
a.envs{p) require 

O. regions. procs.has{p) 
axioms 

a.envs{p) = (J. store. envs (p) 

env.val: STATE ^ PROC ^ NAME ^ REFUPROC 

a.env.val{p,n) require 
O. regions. procs.has{p) 

-^O .store. envs{p). is ^empty A CJ .store .envs (p) .top .names .has (n) 
axioms 

O .env -val{p ,n) = o .store. envs[p). top. val{n) 

Getting attribute values of the current object The auxiliary query att_val takes an object o and a 
name n and returns the attribute value for the attribute with name n of object o. 

att.val : STATE ^ OBJ ^ NAME ^ REF U PROC 

a.attJval{o,n) require 
<J .heap .objs .has{o) 

3a € o. class Jype. attributes: a.name = n 
axioms 

(j.att_val{o,n) = o.att_val{a) 
where 

a o .class Jype .feature Jyy Jiame{n) 
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Getting values of formal arguments, the value of the current object entity, values of local variables, 
the value of the result entity, and attribute values of the current object in a unified way The 

auxiliary queries envjval and attjval define a new auxiliary query val that deals both with values in the 
top environment as well as with values stored in attributes of the current object. The auxiliary query val 
takes a processor p and a name n and it returns the value of n in p's current feature execution context. 
This context consists of the top environment and its reference to the current object. The auxiliary query 
requires that the execution context of processor p is setup properly, i.e., there is a top environment with 
a reference to the current object. The precondition also states that either the top environment has the 
name n registered or the current object has an attribute with name n. In any valid SCOOP program, 
any environment variable has a name that is distinct from the attribute names of the current object. 
This allows us to define the result of the auxiliary query in a simple way. If the name exists in the top 
environment, then the result is the value given by envjval. Otherwise the name must be the name of an 
attribute of the current object, in which case the result is given by att_val. 

val : STATE ^ PROC ^ NAME ^ REF U PROC 
a.val{p,n) require 

O. regions. procs.has{p) 

.store. envs{p). is -empty 
e .names .has{Qurre\it) 

e. names. has{n) V 3c? G o. class Jype. attributes : a.name = n 
where 

def , , 

e = o. store. envs[pj. top 

def 

o = a .heap.ref ^bj{e.val{Current)) 



axioms 



(J.val{p,n) 



' if e .names .hasiji) 
<j.env_val{p,n) 
where 

def , X 

e = <J. store. envs[p). top 
if 3a G o. class -type. attributes: a.name = n 
<j.att_val{o,n) 
where 

e = o. store. envs[p). top 

def 

o = a.heap.ref-obj{e.val{Current)) 



Getting values of once functions The following discussion takes a look at the auxiliary queries to 
access the status of once routines. It describes once routines in general, i.e., it also describe once proce- 
dures. The auxiliary query is_fresh takes a processor p and a once routine /. It returns whether / is fresh 
on p or not. 

isjresh : STATE ^ PROC ^ FEATURE ^ BOOLEAN 

a.isj'resh{p,f) require 

(J. regions. procs.has{p) 

f.is_once 
axioms 

O .is-fresh{p,f) = a.heap.isj'resh{p,f) 
For non-fresh once functions, the auxiliary query onccresult returns the once result of / on p. 
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once .result: STATE ^ PROC ^ FEATURE ^ REF 
o .once -result {p,f ) require 

<7 . regions .procs . has (p) 

f e FUNCTION A /.L9_once 

^o. heap. is -fresh {p,f) 
axioms 

o .oncejresult{p,f) = G. heap. once result{p,f) 
5.6.6 Locking 

This section explores the aspect of the facade that deals with locking. The auxiliary query rq docked 
states whether a processor p's request queue is locked or not. There are no auxiliary queries to distinguish 
between obtained and retrieved locks. Instead, the auxiliary queries rq Jocks and cs Jocks return the set 
of all request queue locks, respectively the set of all call stack locks of a processor p. These locks are 
only usable if they are not passed. This information can be retrieved with a call to the auxiliary query 
locks^assed. 

rqJocked: STATE ^ PROC ^ BOOLEAN 
o.rqJocked{p) require 

<7 . regions .procs . has {p ) 
axioms 

O .rqJocked{p) = o .regions. rqJocked{p) 

rq Jocks : STATE ^ PROC ^ SET [PROC] 
a.rqJocks{p) require 

G . regions .procs . has {p ) 
axioms 

a .rqJocks{p) = a .regions. rq Jocks {p) 

cs Jocks: STATE ^ PROC ^ SET [PROC] 
o.csJocks{p) require 

G . regions .procs . has (p) 
axioms 

a .csJocks{p) = o. regions. cs Jocks {p) 

locks 4)assed: STATE ^ PROC ^ BOOLEAN 
a .locks .passed{p) require 
a . regions .procs . has {p ) 
axioms 

o .locks 4>assed{p) = o .regions .locks 4>assed{p) 

The facade provides auxiliary commands for locking request queues, removing obtained request 
queue locks, unlocking request queues, delegating obtained request queue locks, passing locks, and 
revoking locks. 
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lockj-qs: STATE ^ PROC ^ SET[PROC] ^ STATE 

a . lock^rqs {p , /) require 

(7 . regions .procs . has (p) 

Vx G /: a. regions. procs. has (x) 

Vx G / : a .regions. rqJocked{x) = false 
axioms 

c .lock-rqs{p,l) = G. set{G. regions. lock j-qs{p J), cheap, G. store) 

pop. obtained. rq Jocks: STATE ^ PROC STATE 
G. pop uobtained-rq Jocks (p) require 
<J. regions. procs. has{p) 
^O. regions. obtained j-qJocks{p). is. empty 
G. regions. locks -passed{p) = false 
axioms 

G.pop-obtained-rqJocks{p) = 

G .set{G .regions .pop -Obtained jrqJocks{p) ,G .heap , G. store) 

unlock rq: STATE PROC STATE 
G .unlock j-q{p) require 

G .regions. rqJocked{p) = true 

yq G G .regions .procs : ^G .regions .obtained j-qJocks{q) .flat.has{p) 
axioms 

G .unlock j-q{p) = G.set{G. regions. unlock.rq{p),G. heap, G. store) 

delegate. obtained.rq Jocks: STATE ^ PROC ^ SET[PROC] ^ STATE 
G .delegate obtained rq locks{p, J) require 
G . regions .procs . has {p ) 
VxG/: G. regions. procs. has (x) 

Vx G /: -'By G G .regions .procs : G. regions. obtained j-q Jocks (y). flat. has (x) 
Vx G J: G .regions. rqJocked{x) = true 
axioms 

G .delegate -Obtained jrq Jocks {p , I) = 

G .set(G .regions.delegate.obtainedj-qJocksij), I) , G.heap, G. store) 

pass Jocks: STATE ^ PROC ^ PROC ^ TUPLE [SET [PROC], SET [PROC]] ^ STATE 
G.passJocks{p,q, {lr,lc)) require 

G. regions. procs. has (p) A G. regions. procs. has (q) 

Vx G /r : G .regions. procs. has{x) A Vx G /c • G. regions. procs. has{x) 
\/x &lr: G .regions .obtained-rqJocks{p) .flat .has{x)\/ 

G . regions . retrieved j-q Jocks (p) .flat. has (x) 
Vx G /c: X = G. regions. obtained. csJock{p) V G. regions. retrieved jcs Jocks {p). flat. has (x) 
G .regions. locks -passed{p) = false 
axioms 

G. pass Jocks {p,q, {lr,lc)) = G.set{G. regions. pass Jocks{p,q, {lr,lc)), G.heap, G. store) 
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revoke Jocks: STATE ^ PROC ^ PROC ^ STATE 
o. revoke Jocks {p,q) require 

G. regions. procs. has (p) A a .regions .procs .has (q) 

^G. regions. retrieved _rq Jocks (q) .is_empty A .regions .retrieved -CS Jocks^q) .is -empty 
o. regions. retrieved -rq Jocks {q) .top C 

o .regions. obtained rqJocks{p) .flat U G .regions .retrieved rq Jocks (p) .flat 
G .regions. retrieved _csJocks{q) .top C 

{o. regions. obtained -CsJock{p)} U a. regions. retrieved -cs Jocks (p) .flat 
(J .regions .retrieved^rq Jocks{q) .topU o .regions .retrieved.cs Jocks{q) .top / {} ^ 

o. regions. locks -passed{p) = true 
o .regions. locks -passed{q) = false 
axioms 

G. revoke Jocks {p,q) = o .set{o .regions.revokeJocks{p,q),o .heap, o .store) 
5.7 Simplified state description 

Previous sections formalized the state as an instance of an ADT. Each instance is uniquely described by 
the values of all its queries. However, a description produced in this manner is not practical because it 
is too verbose. This section develops a simplified state description that provides an abstract view on the 
queries of the state. The description is divided into four parts: the locks, the objects, the once status, and 
the environments. Each part is identified with a label. 

The locks part shows for each processor the stack of obtained request queue locks, the stack of 
retrieved request queue locks, and the stack of retrieved call stack locks. It does not show the obtained 
call stack lock because these lock do not change. It uses two indicators to say when a processor's request 
queue is locked or unlocked. It also uses an indicator to state when a processor passed its locks. In 
absence of this indicator, the locks are not passed. 

The objects part shows for each processor the handled objects with their references. It also shows the 
content of the objects. For objects other than arrays or objects of basic class type, the objects part shows 
a list of attribute values, omitting the ones that are void. For objects of basic type, the objects part shows 
the basic value. For arrays, it shows the cells of the array. 

The once status part shows the status of each non-fresh routine. A once routine can be non-fresh 
either with respect to a subset of processors or with respect to all processors. In the first case, the once 
status part shows the once routine in connection with each processor in the subset. In the second case, it 
uses an indicator to denote all processors. 

The environments part represents the store. It shows the environments for each processor. 

Example 4 (Simplified state description). Assume a system with three processors p\, p2, and p^. The 
following simplified state description shows a state in which all request queues are locked. Processor 
pi has a stack of obtained request queue locks with two items. On the bottom of the stack there is the 
set {p2} and on the top there is the set {ps}. Processor pi's stack of retrieved request queue locks and 
retrieved call stack locks each consists of two empty sets. Processor pi passed its locks. From p^'s entry, 
one can see that these locks have been passed from pi to pj. Processor p2 does not have any locks, 
except its own call stack lock. 

In the objects part, one can see that processor pi handles an object oi that is referenced by ri. 
Processors p2 and pj each handle multiple objects. Object 05 is an object with an attribute id that 
references object through the reference rg. Objects og and 04 are objects with the integer values 2 
and 1. Object 02 is a two dimensional array with 2x2 cells. Each of the cells references the object 03 
through the reference r^. 
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The once status part shows two items for the once function id and the once procedure initialize of 
class APPLICATION. The once function id is non-fresh with the value r4 on processor p2- The once 
procedure initialize is non-fresh on all processors in the system. 

The last part shows the environments for the processors. Processor pi has a stack with two environ- 
ments. The environment on the left is at the bottom of the stack and the environment on the right is at 
the top of the stack. Processor p2 has no environments and processor has one environment. In 773 's 
environment there are three mappings. The entity root has the value ri , the current entity has the value 
rs, and the result entity has the void value. 

locks : 

pi :: orq: {{p2},{p3}) rrq: ({},{}) res: ({},{}) locked passed 
P2 :: orq: () rrq: () res: () locked 
P3 :: orq: () rrq: i{p2,P3}) res: ({pi}) locked 
objects : 

pi :: n -^oi 

P2 :: r2 -^02[[r3,r3],[r3,r3]],r3 ->03,r4 -^04(1) 
P3:: rs^05{id^r(,),r(,^0(,{l) 
once status : 

P2:: {APPLICATION] .id ^ u 

all : : {APPLICATION} . initialize 
environments : 

Py" node — r2, Current — )■ ri / node — )• rs, Current — r\ 
Pi ■■■■ 

P3 :: root r\ , Current — )• rj , Result — ;> void 

□ 



6 Formalization of execution 

This section formalizes the execution of a SCOOP program. It explains the general approach, defines the 
starting point of the execution, and explains the rules that drive the execution. The rules are divided into 
rules for mechanisms and rules for code elements. 



6.1 General approach 

The formalization is based on structural operational semantics p9|, combined with parts of the terminol- 



ogy from Ostroff et al. |28 1. The idea behind a structural operational semantics is to define the behavior 
of a program in terms of its parts, i.e., the syntactical elements of the program. Such a semantics is 
intuitive because it talks directly about elements in the code. It is a very powerful semantics because it 
allows us to apply structural induction as a proof technique. 



6.1.1 Computations 

A computation models the execution of a SCOOP program. It is a sequence of configurations, where 
each non-initial configuration is derived from a previous configuration through a transition. Each con- 
figuration defines a state and a list of statements for each processor Each transition is described by an 
inference rule that maps one configuration to another The transition from one configuration to the next 
models an atomic step of one processor. The concurrent execution of a SCOOP program is modeled by 
the interleaved transitions taken by different processors. 
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Example 5 (Modeling of parallel execution). Suppose there are two processors p and q. Processor p 
executes the following sequence of statements: Sp^i;sp^2- In parallel, processor q executes the following 
sequence of statements: Sq^i . This execution is modeled by any of the following simplified computations: 

Sp,i;SpX,Sq,l OT SpX,SqX,Sp^2 OT Sq^r,SpX,Sp^2- □ 

6.1.2 Configurations 

A configuration models a snapshot in the execution of a SCOOP program. A configuration consists of 
a state and a set of processors, each with a queue of statements. The state is an instance of STATE. A 
schedule models the processors and the associated queues, called action queues. Each processor must 
execute the statements in its action queue in a FIFO order. The beginning of the action queue contains the 
statements for the features that are being executed at the moment. The order of these statements models 
the way the call stack orders feature executions. The tail of the action queue is the request queue of the 
processor. A call stack lock is the right to add a feature request to the beginning of the action queue and 
a request queue lock is the right to add a feature request to the end of the action queue. The notation for 
a configuration with processors pi,...,p„, respective action queues si,...,s„, and state a is: 

{pi -.-.sil ... \p„ :: j„,cr) 

The processor separator | is commutative and associative, i.e., pi :: .vi \ pi X2 = pi ^'^2 \ Pi and 
Pi " I {p2 S2 I pz :: sj,) = {pi :: si | p2 :: S2) \ P3 :: sj,. Within an action queue, ; separates statements. 
The configuration is well-defined if and only if j e {l,...,n}: pi = pj. 

6.1.3 Statements 

A statement is an element of the action queue. A statement is either an instruction or an operation. An 
instruction is user syntax, i.e. an action that occurs explicitly in the SCOOP program. An operation is 
run-time syntax, i.e. an action that does not explicitly occur in a SCOOP program. For example, locking 
of request queues is not an action that is expUcit in a SCOOP program. Instead, locking is based on the 
formal argument list. It is done implicitly before a feature gets executed. 

6.1.4 Transitions 

A transition takes a system in a start configuration and leaves it in a result configuration. The following 
shows the general form of a transition definition that declares a start configuration {P, a) with schedule 

P pi :: si \ . . . \ p„ :: s„ and a result configuration {P', a') with schedule P' p\ sW ... \p'^::^^: 

r\-{p,G)^{p',G') 

The typing environment F can be used in the transition definition to access static information about 
the SCOOP program. 

6.1.5 Inference rules 

An inference rule describes the circumstances under which a transition can be used. The inference 
rule has a premise and a conclusion. The conclusion is the transition and the premise describes the 
circumstances under which the transition can be used. The premise consists of a number of transitions 
and a side condition. The premise is satisfied if all transitions in the premise can be taken and if the side 
condition is true. The following shows a template for inference rules: 



45 



General Inference Rule Template 

side condition 
rh(Pi,ap.)^(P(,a;,) 

rh(P„+i,(7p„^j)^(p;+i,(7;„^^) 

In this formalization, most of the rules have no transition in the premise. The following simplified 
inference rule template takes this into account: 

Simplified Inference Rule Template 

condition 

new state o' definition 
fresh channels definitions 

The side condition has three parts. The first part defines a condition that is based on the typing 
environment and the start configuration. The second part is the new state definition that defines the state 
of the result configuration. This new state is based on the state in the start configuration. The last part 
consists of the fresh channels definitions. Auxiliary definitions can be used in the condition, the new 
state definition, and the fresh channels definitions. The inference rule can mention features of STATE. 
The preconditions of these features serve as additional conditions in the side condition. 

The following inference rule generalizes transitions by adding processors both to the start configu- 
ration and to the result configuration. These additional processors run in parallel but do not take any 
actions during the generalized transition. 

Parallelism 

^h(p,(J)^(p^(J^) 

r\-{P\Q,a)^{P'\Q,a') 
6.1.6 Scheduling 

Before a processor can execute a feature it must obtain locks and it must wait until the wait condition is 
satisfied. A locking request encapsulates these two requirements; it consists of the requested locks and 
the wait condition. At every moment, multiple processors can have conflicting locking requests. The 
scheduler is the arbiter for these conflicts. The scheduler takes locking requests and stores them in a 
queue. It then approves locking requests according to a certain scheduling algorithm. 

The model permits a number of possible scheduling algorithms. The algorithms differ in their level 
of fairness and their performance. This formalization does not focus on a particular scheduling algo- 
rithm. Instead, it uses the conditions of the inference rules to express locking requests. If more than one 
processor satisfies the conditions, then any of these processors can proceed. 

6.2 Initial configuration 

The initial configuration is defined by the SCOOP program. Each SCOOP program defines a root class 
type c and a root procedure /. The root procedure is a creation procedure of the root class type that has 
no formal arguments and no precondition. 
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In the beginning, the runtime generates a bootstrap processor p and root processor q with a root 
object of the root class type. The request queue of the root processor is locked on behalf of the bootstrap 
processor. This defines our initial state <7: 

Ox new STATE. ma^e 

Oy Ox-add4)roc[Ox.new 4)roc) 

p Oy.lastjjLdded4>roc 

Gy.add.proc{Oy.new4>roc) 
q O^.last Mdded 4>roc 

de f 

Ow = 0^.add.obj{q,G^.new.obj{c)) 
def 

r = o„.ref{Ow.last_added_obj) 

def 

C = aw.lock_rqs{p,{q}) 

The bootstrap processor first asks the root processor to execute the root procedure on the root object 
and then asks the root processor to unlock its request queue as soon as it finished the execution. The 
bootstrap processor can do this because it has the request queue lock on the root processor. Finally, the 
bootstrap processor removes the request queue lock from its stack of obtained request queue locks. This 
is shown in the following initial configuration: 

( 

/.::call(r,/,(),()); 
issue unlock); 
pop_obtained_rq_locks | 

q:: 
a 

) 

The statements call, issue, unlock, and pop_obtained_rq_locks are operations. In a nut- 
shell, the call(r,/, (), 0) operation asks the handler of the target r to make a call to the feature 
/ on target r. The unlock operation unlocks the request queue of the processor that executes the 
operation. The issue(i7, unlock) operation adds the unlock operation to q's action queue. The 
pop_obtained_rq_locks operation removes the top element from the stack of obtained request queue 
locks. 

Example 6 (Initial configuration). This example defines the initial configuration of a shai^e market ap- 
plication. The domain of the application consists of a number of markets, a number of investors, and 
a number of issuers. Each issuer can offer a number of shares on each market. Each investor can have 
an amount of cash available on each market. With this cash, the investor can buy the shares that are 
available on the market. Investors can sell a share on the market where they bought the share. Selling 
shares increases the investor's amount of cash on the market. Each market determines the price for each 
share. Financial regulations require the investors to keep track of the markets on which they operate. For 
simplicity, the price is constant and the application is restricted to one market, two investors, and one 
issuer with one share. 

The class MARKET represents the market; the class INVESTOR represents the investor. The issuers 
are represented through identifiers of class INTEGER. The root class APPLICATION contains the root 
procedure make, where the actors get created and where the trade begins. 
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The execution starts with a bootstrap processor po, a root processor pi and a root object oq of root 
class type APPLICATION. The root object is referenced by ro- The following initial configuration shows 
this: 

( 

po :: call (ro,ma^e, (),()); 
is sue unlock); 
pop_obtained_rq_locks | 

Pi ■■■ 
locks : 

Po:: orq: {{pi}) rrq: () res: () unlocked 
pi :: orq: () rrq: () res: () locked 
objects : 
Pq ■■■ 

pi :: ro oo 
once status : 
environments : 

PO ■■■■ 

P\ ■■■■ 

) 

□ 

6.3 Mechanisms 

Mechanisms are the machinery for the execution of code elements. This section studies these mecha- 
nisms. 

6.3.1 Issuing meclianism 

With the issuing mechanism, a processor p can add statements to the action queue of a processor q. It 
uses the issue operation to get a result configuration in which a processor's action queue is extended 
with the new statements. There are two main cases: p adds the statements to its own action queue, i.e., 
p = q, or p adds the statements to the action queue of a different processor, i.e., p ^ q. The first case is 
the non-separate case and the second one is the separate case. 

For the non-separate case p puts the statements to the beginning of ^'s action queue, which is the 
same as putting the statements on top of the call stack. This requires that p is in possession of its own 
call stack lock. 

Issue Operation - Non-Separate 

q = p 

-1 (7 . locks 4)assed {p ) 
a.csJocks{p).has{q) 

r\- {p:: ±ssue{q,s^.);sp,a) {p :: s„;sp,a) 

For the separate case there is a difference between a normal and a callback case. In the normal case, 
p adds the statements to the end of ^'s action queue. This case requires that p is in possession of ^'s 
request queue lock. To distinguish the normal case from the callback case, this case also requires that q 
does not have a lock on p. 
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Issue Operation - Separate 

-1 a . locks passed (p) 
O.rq Jocks (p). has (q) 

-^{a .rqJocks{q) .has{p) V O .csJocks{q).has{p)) 
rh (p :: ±ssue{q,Sw);sp \ q :: Sq,o) ^ {p::sp\q :: Sq;sw,o) 

The callback case occurs if q has a lock on p. In this situation, p could issue a statement s„ on ^ and 
then wait for q to complete. On the other side, processor q could already be waiting for p to complete. 
Processor q would be waiting for p to finish and p would be waiting for q to finish. However, since s^, 
would be at the end of ^'s action queue and q would be waiting there cannot be any progress. This type 
of deadlock can be prevented by adding s„ not to the of q's action queue but to the beginning. This will 
make sure that q can execute the statement right away and hence p can continue. This in return will 
enable q to continue. As a prerequisite, p must possess ^'s call stack lock. 

Issue Operation - Separate Callback 

.locks 4>assed{p) 
O.cs Jocks (p). has (q) 

O .rqJocks{q) .has{p) V o .csJocks{q).has{p) 
rh (/? :: ±ssue{q,s^);sp \ q :: 5^, a) {p::sp\q :: s„;Sq,o) 

6.3.2 Delegated execution mechanism 

This section discusses how a processor q can delegate the execution of statements to a different proces- 
sor p. This mechanism is useful for the evaluation of asynchronous postconditions. Processor q must 
make sure that the statements make sense in the context of processor p. The names that occur in these 
statements must be defined in the top environment of p and p must have the necessary locks to execute 
the statements. Statements that fulfill the following conditions can be delegated: 

• All names that occur in the statements are defined in ^'s top environment. 

• Their execution only requires the top set of g's stack of obtained request queue locks. 

These conditions exclude statements that involve non-separate calls or separate callbacks because such 
calls require a call stack lock. If these conditions are met, q can transfer its top environment and the top 
of its obtained request queue locks to p. Given this context, p can then execute the delegated statements 
instead of q. 

The execute_delegated(5'w,x, {^1, . . . operation sets up a new context on p with an en- 

vironment X and obtained request queue locks {^1, . . . ,^,„}. To set up the new context, the opera- 
tion uses a combination of the commands push_env and delegate. obtained. rq Jocks. The command 
delegate ^obtained^rq Jocks requires that the request queue locks {qi,. . . ,qm} are not in possession of 
another processor anymore. It also requires that the request queues of {qi,. . . ,q,n} are locked. Once 
the context is set up, processor p executes the statements s^ and then gets rid of the context, using the 
leave_delegated operation. 

To delegate the execution of the statements s^, processor q must make sure that its top environ- 
ment X is set up correctly and it must make sure that the top set of its obtained request queue locks 
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contains all locks {qi, . . . ,q,„} that are necessary for the execution of Sw Processor q must then is- 
sue a execute_delegated(5'iv,;c, {^i, . . . ,qm}) operation to processor p. Processor q must then remove 
{^1, . . .,qm} from its stack of obtained request queue locks so that the delegate -obtained-rq Jocks oper- 
ation can take place. 

Execute Delegated Operation 

yx £ {qi,- ■ ■ ,qm} '■ ~'^y G O.procs: o .rq Jocks {y) .has {x) 
\/x G {^1, . . • ,^m} '■ O.rqjocked{x) 

def 

o' = o.push_env{p,x) .delegate _obtained-rq Jocks {p , {qi , qm}) 

r\-{p :: execute_delegated(i'„,,x, {^i, . . . ,qm})',Sp, (j) — )• 
{p :: 5^; leave.delegated;^^, a') 

Leave Delegated Execution Operation 

.envs{p) .is^empty 
^G. obtained -rq Jocks (p). is .empty 

a' o. pop. env{p). pop. obtained j-qJocks{p) 
T\- {py. leave_delegated;i'p,a) — t- {p :: Sp,<j') 

6.3.3 Notification mechanism 

Processors can notify each other. A notification can optionally include a value. The formalization uses 
channels to describe such communication. Channels are described in Milner's Ti-calculus {24]. In the 
TT-calculus, the expression c{x).P denotes a process that is waiting for a notification sent on a channel c. 
Once the notification has been received, the value of the notification is bound to the variable x and the 
process continues with the expression P. The notification comes from a process that executes cy.Q to 
emit the value y on the channel c before executing Q. 

The formalization reuses the channel idea in two flavors: once as a notification mechanism with a 
value and once as a notification mechanism without a value. A processor sends a notification with a value 
r over a channel a as it executes the operation result(a,r). Similarly, the process sends a notification 
without a value over a channel a by executing the operation notif y(a). For both cases, any processor 
can wait for a notification by executing the operation wait (a). In case a notification on a channel a 
carries a value, the value can be accessed with a.data. This way of accessing the value of a channel is 
different from the way it is done in the TT-calculus. In the Ti-calculus, each value is bound to a variable. 
This formalization does not define a new variable for the value. Instead, it uses a.data to identify the 
value of a channel a. 

A number of inference rules describe the interaction between a processor that sent a notification over 
a channel and a processor that is waiting for a notification over the same channel. Two main cases can 
be distinguished: either a processor sends a notification to itself or it sends a notification to a different 
processor. The first case is the non-separate case and the latter case is the separate case. In each of these 
two main cases, the channel carries a notification with or without a value. For each of these sub cases, 
there is one inference rule. 

In the non-separate case, one processor has a result(a, r) operation or a notif y(a) operation at the 
beginning of its action queue and a wait (a) operation on the same channel later in the action queue. In 
this case, the wait(a) operation can be removed along with the result(fl:,r) operation, respectively the 
notif y(fl') operation. If the channel carries a value, then the value must be installed on the processor, 
by substituting all occurrences of a.data with the posted value in all the statements Sp after the wait (a) 
operation. 
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Wait and Result Operation - Non-Separate 



r\- {p:: result{a,r);sw',v3.it{a);sp,a) — {p :: Sw',Sp[r/a.data],(j) 
Wait and Notify Operation - Non-Separate 



r\- {p:: notify(a);5vv,;wait(a);5p,a) {p :: s„;sp,a) 

In the separate case, one processor has a result(fl,r) or a notify(a) operation at the beginning 
of its action queue and a different processor has a wait (a) somewhere in its action queue. In this 
situation, the wait(a), result(a,r), and notify(fl:) can be removed from the action queues. In case 
the notification has a value, the value can be installed in the statements Sp, after the wait (a) operation. 

Wait and Result Operation - Separate 



r\- {p :: wait(a);5p | q :: result(a,r);5^,a) — {p :: Su,;sp[r/a.data] \ q :: Sq,a) 
Wait and Notify Operation - Separate 



rh (p :: 5„,.; wait(a);5p | q :: notif y(a);5^, a) — {p :: Sw',Sp \ q :: 5^,cj) 

The operations presented here must be used so that each wait operation can be resolved with exactly 
one result or notify operation. To define this condition more precisely, we define that one statement 
si weakly precedes a statement ^'2 if and only if si occurs earlier than S2 in the same action queue or s\ 
and S2 occur in different action queues. One statement si strongly precedes a statement s\ if and only if 
si occurs earlier than ^2 in the same action queue. With these definitions, the condition says: 

• For each wait (a) operation there must be either exactly one result(a,r) or exactly one 
notify (a) operation. 

• For each result(a,r) or notif y(a) operation there must be exactly one wait(fl;) operation. 

• Each result(a,r) or notif y(a) operation weakly precedes the wait(a) operation. 

6.3.4 Expression evaluation mechanism 

An expression can either be a literal, an entity, or a query call. The query call can contain actual ar- 
guments that are expressions themselves. This section discusses the general mechanism to evaluate 
expressions. It focuses on the general approach and defers the evaluation of particular expressions to 
later sections. 

The operation eva.l{a,e) takes a channel a and an expression e. Each eval(a,e) operation deter- 
mines the value r of the expression e and then sends a notification with value r on channel a. This means 
that each eval(a,e) operation creates a result (a, r) operation in the action queue. It is therefore im- 
portant to follow each eval(a,e) operation with exactly one wait (a) to receive the notification with the 
value. 
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6.3.5 Locking and unlocking mechanism 

A processor p that wants to execute a feature must first obtain the request queue locks of a number of 
processors {^i, . . . ,qm}- Only then can p issue statements to these processors. The lock({^i, . . . ,q,n]) 
operation serves this purpose. It requires that none of the request queues is already locked. 

Lock Operation 

-^3qi e{q\,.. .,qm} ■ O .rqJocked{qi) 
o' a.lock.rqs{p,{qi,. . .,qm}) 
r\- {p:: lock{{qi, . . . ,q,„});sp,a) {p :: Sp,a') 

Once p is done with the execution of the feature, it asks {^i, . . . ,qm} to unlock their request queues 
once they are done with the issued statements. For this purpose, p issues the unlock operation to 
processors {q\,...,qm}. This operation requires that the request queue is indeed locked and that no 
processor possesses the request queue lock. 

Unlock Operation 

a.rqJocked{p) 

yq G O.procs: ^O.rq Jocks (q). has (p) 

a' "t^ o .unlock j-q{p) 

T\- {p:: uiilock;5p, a) — {p :: Sp, a') 

After p issued the unlock operations, it can remove {^i, . . . ,^„,} from its stack of obtained request 
queue locks using the pop_obtained_rq_locks operation. This ensures that the unlock operations can 
proceed. 

Pop Obtained Request Queue Locks 

def 

a' = a. pop -Obtained -rq Jocks (p) 
r h (p :: pop_obtained_rq_locks;5p, a) — t- {p :: Sp, a') 

Brooke, Paige, and Jacob f5l noticed that unlock operations are not optimal. In essence, it could be 
possible to unlock the request queue of a processor qi directly after p issued all statements. The request 
queue lock is important to guarantee exclusive access on ^,'s request queue. However, as soon as p 
issued all statements on qi, this lock is no longer needed. Unlocking the request queue right away could 
improve the performance in some situations because qfs request queue could be locked again earlier and 
hence another processor that is waiting for this lock could proceed earlier. 

6.3.6 Write and read mechanism 

A processor p can use the yrite{x,v) operation to set a value v of an entity with name x. This operation 
uses the set_val command. Hence, p can both set attribute values of its current object and values of 
entities in its top environment. 

Write Value Operation 

a = o.set_val[p,x,v) 
r\- {p:: ^rite{x,v);sp,o) {p :: Sp,o') 



52 



Similarly, processor p can execute the read(x,a) operation to read a value of an entity with name x 
and send the value over channel a. The read operation does not present its result in a result operation 
because, unlike an eval operation, a read operation always produces a result for the surrounding action 
queue. It is easier to do the substitution of the channel access directly. A later section introduces the eval 
operation for entity expressions. This variant of the eval operation makes use of the read operation and 
presents the result in a result operation. 

Read Value Operation 



T\- {p:: read(x,fl');5p,a) — )• {p :: Sp[o.val{p,x)/a.data\^o) 

Finally, there is the set jiot_f resh operation in two variants for once functions and one variant for 
once procedures. This operation sets the once status of a once routine. The variant set jiot_f resh(/,r) 
sets the once status of a once function / to non-fresh with value r. If / is of separate type, then the once 
function becomes non- fresh on all processors in the system. If / has a non-separate type, then / becomes 
non-fresh only on processor p. The variant set_not_f resh(/) sets the once status of a once procedure 
/ to non-fresh on processor p. The variant set jiot_f resh_with_result uses the value of the result 
entity to set the once status of a once function. 

Set Once Routine Not Fresh Operation - Function 

/ e FUNCTION A/. w-oncf- 

a' (j.set-once-func-not-fresh{p,f, r) 
T\- {p :: set_not_fresh(/,r);5p,a) — t- {p :: Sp,<j') 

Set Once Routine Not Fresh Operation - Procedure 
/ G VROCEDUREAf is once 
a' ^= (j.set_once-procJiotJresh{p,f) 

r\- {p :: set_not_f resh(/);5'p, a) — )• {p :: Sp, a') 

Set Once Routine Not Fresh Operation - Function With Result 



T\-{p :: set_not_f resh_with_result(/);5p, a) — )■ 

{p :: read(Result,fl); set jiot_f resh(/,a.(iato);i'p, a) 

6.3.7 Flow control mechanism 

In addition to flow control instructions in the user code, there are flow control operations, which imple- 
ment flow control in the inference rules. This way, fewer inference rules are required because multiple 
variants can be handled in one inference rule. 

The provided x then St else Sf end operation takes the condition x as an argument. The operation 
either executes Sf if x indicates that the condition is true or Sf if x indicates that the condition is false. For 
each possibility there is one inference rule. The condition x can either be an instance of BOOLEAN or 
it can be a reference that points to an object of class type BOOLEAN. To decide which branch to take. 



/ G FUNCTION A /./sconce 

(J .envs(p) .top .names .has(Resuit) 

a is fresh 
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the operation must evaluate x. If x is an instance of BOOLEAN, then it can determine which instance 
X is, i.e., true or false. If x is a reference, then it must get the referenced object and see which boolean 
value it represents. For this purpose, it evaluates the attribute item of the referenced object. 

Conditional Operation - True 

{X ifx G BOOLEAN 

o .att_val{o .ref.obj{x) , item) ifx G REF A o .ref.obj{x) .class Jype = BOOLEAN 
false otherwise 
y = true 

T\- {p provided X then St else Sf end;^^, o) ^ {p St',Sp,o) 

Conditional Operation - False 

{X ifx G BOOLEAN 

O .att _val{o .ref _obj{x) , item) ifx G REF A O .ref -obj{x) .class Jype = BOOLEAN 
true otherwise 
y = false 

r h (p :: provided x then St else Sf end;^^, a) — t- {p :: Sf;Sp, o) 

The provided x then St else Sf end operation has two branches. Sometimes it is necessary to only 
have one branch. The nop operation can be executed without an effect. It can be used in the conditional 
operation to define an empty branch. The nop operation can also be used to indicate that an action queue 
is empty. 

No Operation 



Fh :: nop;5p,a) {p :: Sp,o) 
6.4 Code elements 

This section explains the semantics of code elements: entity expressions, literal expressions, feature 
calls, feature applications, creation instructions, flow control instructions, and assignment instructions. 

6.4.1 Entity expressions 

A variant of the eval(a,e) operation evaluates entity expressions. The operation uses the read operation 
to send a notification with the value of the entity over a new channel a' . It then uses the value of this 
channel to define the result of the eval operation. 

Entity Expression 

e G ENTITY 

a' is fresh 

Fh (/J :: eval(a,e);5p, a) — )■ {p :: Te3.d{e.name,d)\resM'l.t{a,d .data);sp,o) 
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6.4.2 Literal expressions 



Another variant of the eva.l{a,e) operation evaluates literal expressions. To evaluate a non-void literal 
expression, the operation creates a new object of the literal class type so that the new object represents the 
literal value. For this purpose, it uses the query obj of LITERAL. Since the type of every literal is non- 
separate, it creates the new object on the processor that evaluates the literal expression. The reference r 
to the new object is the result of the evaluation. To evaluate a void literal, the operation takes the void 
reference. 

Literal Expression 



r\- {p:: eva.l{a,e);sp,(j) — )• {p :: result(a,r);5p,a') 
6.4.3 Feature calls 

A feature call can occur in two ways. First, a feature call can be a call to a command in a command 
instruction. Second, a feature call can be a call to a query in an expression. This section studies both 
variants. A processor p that executes a feature call eo./(ei, . . . ,€„) goes through the following steps: 

1 . Target evaluation. Evaluate the target expression eo and let q denote the handler of the target. 

2. Argument passing. Evaluate the actual arguments expressions {ei,... ,e„). 

3. Lock passing. Determine which locks to pass to q. 

• Take all request queue locks and call stack locks if a controlled actual argument gets attached 
to an attached formal argument of reference type. 

• Take all request queue locks and call stack locks if the feature call is a separate callback, i.e., 
q has a lock on p. 

• Otherwise, take no locks. 

4. Feature request. 

• Ask q to apply / to the target immediately and wait until the execution terminates if any of 
the following conditions holds: 

- The feature call is non-separate, i.e., p = q. 

- The feature call is a separate callback, i.e., q has a lock on p. 

• Otherwise, ask q to apply / to the target after the previous feature requests. 

5. Wait by necessity. If / is a query, then wait for the result. 

6. Lock revocation. If lock passing happened, then wait for the locks to come back. 

A command instruction is a statement in the action queue. A query is an expression on the right hand 
side of an assignment, a condition in a flow control instruction, or an actual argument in a feature call. 
Whenever a query occurs in one of these constructs, the inference rule of the construct encloses the query 



e G LITERAL 
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in an eval operation. To iiandle feature calls, there is an inference rule for command instructions and a 
variant of the eval operation for query calls. 

In each case, the statement first evaluates the target expression and all actual argument expressions. 
For each of these expressions ej, it uses one eval(ae.,e,) operation and a corresponding wait(ae.) oper- 
ation with a fresh channel a^,-. Each of the channel values gets used in the subsequent call operation. 
With this, the statement handled the target evaluation and the argument passing step. It defers the attach- 
ment of the actual arguments to the formal arguments to the point where the called feature gets applied. 
The reason for this is simple: at this point the context for the feature application does not exist yet. 

The call operation takes care of the remaining steps. The operation exists in two variants, one 
for command instructions and one for queries. The variant for queries takes a channel a' and uses it 
for the result of the query. Since a call to a command does not produce a result, such a channel is not 
required for command instructions. Both call variants take the reference to the target > the feature 
/ to be called, the references to the actual arguments {ag^. data, ... ,ae„. data), and the actual argument 
expressions (ei, . . . The actual argument expressions are used to check whether there is a controlled 
actual argument. This information determines whether the locks should be passed. 

Command Instruction 



Query Expression 

V/ € {0, ...,«}: £?(,,. is fresh 
a' is fresh 

r\-{p :: eva.l{a,eo.f{ei, . . . ,en));sp,a) 

{p : : eval (a^g ,eo); eval (a^, ,ei);...; eval {ae„ , e„) ; 
wait {aeo ) ; wait (a,., );...; wait (a^,, ) ; 
ca.ll{a' ,aeg. data, f, (a^j .data, . . . ,ae„.data), (ei, . . . ,e„)); 
res\ilt{a,a .data); 



Both variants of the call operation take the reference to the target r„, the feature / to be called, 
the references to the actual arguments (ri , . . . , r„), and the actual argument expressions {e\, . . . ,e,i ). The 
variant for queries takes an additional channel a to be used for the result of the query. In a first step, 
the operation must evaluate the handler q of the target. The handler is used in an issue operation to 
issue a feature request on the responsible processor. The feature request comes in the form of an apply 
operation. The apply operation takes a channel a for the communication between p and q, the target 
reference ro, the called feature /, the references to the actual arguments (ri , . . . , r„), the caller processor 
p, and the passed locks 1. 

Clarification 3 (Lock passing). Processor p passes all its request queue locks and all its call stack locks 
either if there is a controlled actual argument that will get attached to an attached formal argument of 
reference type or if the feature call is a separate callback. An attached formal argument of reference 
type means that the request queue lock or the call stack lock on the actual argument's handler is required 
during the application of /. A controlled actual argument means that p has a request queue lock or a 



V/ € {0, . . . ,n}: ag. is fresh 



rh(p: 

if- 



eo.f{ex,...,en);sp,o) 

eval(ago,eo);eval(ae, . . . ;eval(ae„,e„); 
wait(aeQ); wait(ae, ); . . . ; wait(ae^); 
ca.ll{agQ. data, f , (ag^ .data, . . . ,ae^^.data),{e\ 



(^n)); 
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call stack lock on the handler of the actual argument. In short, p has a lock that is required by q and 
thus p has to pass the locks. A separate callback occurs if q has a lock on p. In this situation, p can 
issue a statement to q and then wait for q to complete. However, processor q could already be waiting 
for p to complete. To handle this case, the issue operation in the call operation triggers an immediate 
execution by adding the apply to the beginning of ^'s action queue. The issue operation requires that 
p has the call stack lock of q. To enable q to perform an immediate execution, p has to give back ^'s call 
stack lock. 

In both cases, p has to wait for the locks to come back. Thus it does not hurt to pass all the locks in 
both cases. In contrast to Nienaltowski's |j25l| description of SCOOP, p only passes the locks that it really 
has. In particular, p does not pass its own request queue lock in situations where p does not possess this 
lock, such as when the processor that called p possesses /^'s request queue lock. □ 

In the cases where the operation passes the locks, I is {a.rq Jocks {p),G.cs Jocks {p)). In all other 
cases there is no lock passing and thus I = ({},{}). The operation just determines which locks to pass. 
The actual lock passing action will be executed by q. Similarly, the actual lock revocation action will be 
executed by q. 

For command calls, lock passing is the only reason to wait. In this case, the operation creates a fresh 
channel a to wait for a notification from q. The notification arrives when q is ready to return the locks. 
For query calls, the operation has to wait for the result. The operation uses the given channel a to wait 
for the result. This has the advantage that once the result arrives, it will be substituted after the call 
operation, i.e. in the result operation of the eval operation. 

Call Operation - Command 

q G .handleriro) 
'if 

^ 7^ 7? A3/ G {1, . . . ,«} : F h g,- : t A controlled (t) AF h f .formals{i) : (!,g,c) Ac.is-ref 
then 

{G.rqJocks{p),<J.csJocks{p)) 

if 

q ^ p A {(J.rqJocks{q).has{p) y o .csJocks{q).has{p)) 
then 

{(J.rqJocks{p),a.csJocks{p)) 
otherwise 

({},{}) 
a is fresh 

rh{p :: call(ro,/, (n, ■••,''„), (ei, ... ,e„));5p,_a) 
{p :: issue(^,apply(a,ro,/,(ri,...,r„), ;?,/)); 

provided / ^ ({},{}) then wait(a) else nop end; 
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Call Operation - Query 

q o .handler{ro) 
'if 

q ^ p A3i £ {I , . . . ,n} : F h e,- : t A controlled (t) AT h f .formals{i) : (!,g,c) Acis-vef 
then 

(o .rqJocks{p) ,<J .csJocks{p)) 

if 

q ^ pA {a .rqJocks{q) .has{p) V (J .csJocks{q) .has{p)) 
then 

{cj.rqJocks{p),<J.csJocks{p)) 
otherwise 

({},{}) 

rh(p :: ca.ll{a,ro,f,{ri,...,rn),{ei,...,en));sp,a) 

{p :: issue(^,apply(a,ro,/, (n, ••• ,?•„),/?,/)); wait(a:);i'p,a) 



Example 7 (Feature call). This example demonstrates the inference rules for feature calls. For this pur- 
pose, consider again the share market example. Suppose the root processor p\ started with the execution 
of the procedure doJransaction on the root object oq. This procedure is shown in Listing[T] 



Listing 1 : Application class with implementation 

dass APPLICATION 



create 

make 



feature — Initialization 
make 
do 

end 



feature {APPLICATION} Implementation 

market: separate MARKET 
The market. 



doJransaction ( 
first Investor, separate INVESTOR; 
secondJnvestor. separate INVESTOR; 
issuer Jd: INTEGER 

) 

— Make each of the two investors buy and then sell a share of the issuer, 
do 

firstJnvestor.buy {Qnrreni.market, issuerJd) 
secondJnvestor. buy (Current.market, issuerJd) 
first Jnvestor. sell (Current.market, issuerJd) 
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second Jnvestor. sell {Current.market, issuer Jd) 
end 

end 

The following configuration is our starting point. Processor p\ has one environment for the callee 
procedure make and one for the called procedure doJransaction. Processor p2 handles the market object 
035, processor handles the first investor object 044, and processor pa, handles the second investor object 
046- The market object references three arrays. The cash array 025 shows that each investor has the same 
amount of cash. The available shares array 033 shows that there is one issuer with one available share. 
The owned shares array 038 shows that none of the investors owns a share. The action queue of p\ 
indicates that p\ is about to make the feature calls on the two investors. For this purpose, py obtained the 
request queue locks of their handlers. 

( 

pi :: first _investor.buy{current .market , issuer Jd); 
second Jnvestor.buy (current. market , issuer Jd); 
firstJnvestor.sell {current. market , issuer Jd); 
second Jnvestor.sell (current .market , issuer Jd) ; 

P2 :: \ P3:: I P4 ■■ 

locks : 

Pi ■■ orq: ({},{P^^P^}) m' ({},{}) res: ({},{}) locked 
P2 :: orq: () rrq: () res: () unlocked 
P3 :: orq: () rrq: () res: () locked 
P4 :: orq: () rrq: () res: () locked 
objects : 

p\:: ro ^ oo(market ^ ri),rT,i) ^ 04g{l) 

Pi fi — ^ OT,$(cash —7- ri^, available shares — ?• r23,ownedshares — )• r29), 
ne^ 025[r2i,r22],r2i 023(100), r22 024(100), 
r23 033 [r2$] , r28 032 ( 1 ) , 

r29 038[[r34], [r35]],r34 O4l(0),r35 042(0) 

P3:: re 044(2^/-^ '"36),'"36 043(1) 

P4--- rs 046 (id r37 ) , r^j 045 (2) 
once status : 
environments : 

pi first Jnvestor ^ r^, second Jnvestor ^ rg, Current — >• ro / 

first Jnvestor — t- rg , secondJnvestor — t- rg , issuer Jd — )■ r^g , Current — t- tq 

P2 ■■■ 
P3 ■■■ 
PA ■■■■ 

) 

The inference rule for command instructions leads to the following configuration, with fresh channels 
«59> ^260, and agi: 
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( 

Pi :: eval(a5^ , first .investor); 
eval (ago j current .market); 
eval (agi , issuer Jd) ; 
wait (059); 
wait(a6o); 
wait(a6i); 

call ((359 .data, buy, {a(,o.data,a(,i .data) , (current. market , issuer Jd) ) ; 
second Jnvestor.buy (current. market , issuer Jd); 
first Jnvestor.sell (current .market , issuer Jd) ; 
second Jnvestor.sell (current .market , issuer Jd) ; 

P2 :: I ;?3 I /'4 :: 

) 

First pi has to evaluate the target expression and the actual argument expressions. This leads to the 
following configuration: 

( 

p\ :: call(r(,, buy, (ri,r^()),(current.market, issuer Jd)); 
second Jnvestor.buy (current. market , issuer Jd); 
first Jnvestor.sell (current. market , issuer Jd); 
second Jnvestor.sell (current .market , issuer Jd) ; 

P2 :: \ P3:: I P4 

) 

During the execution of the call operation, pi determines that no locks need to be passed. Then pi 
executes an issue operation to enqueue an apply operation to the action queue of the first investor's 
handler. □ 

6.4.4 Feature applications 

A feature call by a client processor q results in a feature request for a supplier processor p. A feature 
application is the serving of the feature request. This section discusses how p applies a feature / on a 
target referenced by tq. Processor p takes the following steps: 

1 . Once status update. If / is a once routine, then set its status to non-fresh. 

2. Lock passing. Pass the locks from q to p. 

3. Argument passing. Bind the actual arguments to the formal arguments. Arguments of expanded 
type that are handled by a different processor than p must be deep imported by p. 

4. Synchronization. Involve the scheduler to wait until the following synchronization conditions are 
satisfied atomically: 

• Processor p owns the request queue lock of each processor q such that: 
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- Processor q handles an actual argument of / and the corresponding formal argument has 
an attached reference type. 

- Processor p and processor q are different. 

- Processor p does not have ^'s request queue lock. 

- Processor q does not have p's request queue lock. 

• The precondition of / holds. 

5. Execution. 

• If / is a non-once routine or a fresh once routine, then run its body. 

• If / is a non-fresh procedure, then do nothing. If / is a non-fresh function, then take its once 
value as the result. 

• If / is an attribute, then evaluate it. 

6. Postcondition evaluation. Evaluate the postcondition if any of the following conditions is satisfied: 

• A feature call in the postcondition requires a lock that was not obtained in the synchronization 
step. 

• The evaluation of the postcondition involves lock passing. 

Otherwise ask any processor whose request queue lock was obtained in the synchronization step 
to evaluate the postcondition. 

7. Lock releasing. Ask each processor whose request queue has been locked in the synchronization 
step to unlock its request queue after it is done with the feature requests issued by p. 

8. Invariant evaluation. If / is a routine, then evaluate the invariant. 

9. Result returning. If / is a query, then return the result to q. If the result is of expanded type and 
p q, then the result must be deep imported by q. 

10. Lock revocation. Return the passed locks from p to q. 

Each feature application starts with an operation apply(a,ro,/, {r\,.. . ,r„),qj) in the action queue of 
processor p. The channel a is used to communicate with the client processor q. If the called feature / is 
a procedure and the caller processor q passed some locks, then a is used to signal that the locks returned. 
If / is query, then a is used to return the value. The reference points to the target of the call. The 
references (ri , . . . , r„) point to the actual arguments. The tuple I contains the locks to be passed from q 
to p. 

If one takes a look at the execution step, one can differentiate three cases: 

• The feature / is a non-once routine or a fresh once routine. 

• The feature / is a non-fresh once routine. 

• The feature / is an attribute. 

For each of these cases, there is one inference rule. Each inference rule covers one variant of the apply 
operation. The discussion continues with the most involved case: the feature / is a non-once routine or 
a fresh once routine. 
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Application Operation - Non-Once Routine or Fresh Once Routine 

/ G ROUTINE A f .is ^once o.isJresh{pJ) 
<J .handler{ro) = p 

-^O .pass Jocks{q^p~l). locks -passed{p) 

O .set _once June _not_fresh{p,f , void) iff G FUNCTION A/. w.once 
o' = I G.set-onee-proe-notJresh{p,f) if f £ PROCEDURE A f .is -onee 



a otherwise 
issJi 

def 



def 

t" = a' .passJocks{q,p,l).push.envjwithJ'eature{p,f,rQ, (n, . . . ,r„)) 



6 required J ocks 

{x G PROC I 3/ G {1, . . . ,?i},g,c: T h f .formals{i) : (!,g,c) Ac.is.ref Ax = o" .handler {ri)} 

def 

8 required _cs Jocks 

e g required Jocks \ x = py [xi^pA [o" .rqJocks{x) .has{p) V a" .csJocks{x).has{p)))} 

Srequired^rq Jocks 8 required Jocks \ 8 required _cs Jocks 

8 missing j-q Jocks = ^8 required _rq Jocks I ^o" .rqJocks{p) .has{x)} 
'^^^ 8 required^cs Jocks' O" .CsJocks{p) .has{x) 

aim, fresh A a' is fresh 

rh{p :: a.pply{a,ro,f,{ri,...,rn),qJy,Sp,a) 
{p :: check_pre_and_lock_rqs(f„„„.;„g 

provided / G FUNCTION A/. /5_o?ice then 
f.body 

[result :=y; set jiot_f resh_uith_result(/)/rei'MZf :=j] 

[create re™Zf.j; set jiot_f resh_with_result(/)/create result.y] 

else 

f.body 
end; 

check_post_and_unlock_rqs(g^;„,„g,^j„^fc„/); 
provided f .class Jype.inv -exists A f .exported then 

eval {ainv , f .class Jype.inv) ; wait (a,-„v) 
else 

nop 
end; 

provided / G FUNCTION then 

read(Result, a') ; i:etxirn.{a,a' .data,q) 
else 

return(a,^) 
end; 

The condition of the inference rule states that each processor can only apply a feature on one of its 
own objects. The condition also states the p must not have passed its locks. This part of the condition 
is always given because p waits whenever it passes its locks. In a first step, the operation defines an 
updated state o' to set /'s once status to non-fresh, in case / is a once routine. The operation does this 
before deep importing the actual arguments to avoid the following contradiction. 

Clarification 4 (When to change the status of afresh once routine). Assume / is either a once procedure 
or a non-separate once routine. The feature / was fresh at the beginning of the apply operation. Assume 
that the caller passed an expanded actual argument that is handled by a processor gi^ p. Therefore p has 
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to deep import the actual argument. Assume furthermore that the class type of the actual argument has 
the once routine / and that / is non-fresh on g. If the operation would deep import before setting / as 
non-fresh on p, then the deep import operation would take over the once status of / from processor g to 
processor p. But then the apply operation on p would not make much sense anymore because / would 
now be non-fresh on p. If the operation sets / as non-fresh at the beginning of the apply operation, then 
the deep import operation does not take over the once status from g because / is already non-fresh on p. 
□ 

The operation defines an updated state a" in which the locks are passed from q to p and in which 
there is a new environment with the actual arguments (ri , . . . , r„). The call to the push_env jwithj^eature 
feature takes care of copying and deep importing actual arguments of expanded type. The caller processor 
q can also pass an empty tuple ({},{}) which simply means that q did not pass any locks. 

In the next step, the operation synchronizes. For each target expressions in the body of /, the oper- 
ation can get the controlling entity. Each of these controlling entities is mapped to an object and each 
of these objects is handled by a processor. For each of these processors the operation must either get a 
request queue lock or a call stack lock. There are three types of calls: non-separate calls, separate calls, 
and separate callbacks. Non-separate calls and separate callbacks require a call stack lock. Separate calls 
require a request queue lock. This leads to two sets of required locks: one set with required request queue 
locks and another set with required call stack locks. The set of required call stack locks is composed of p 
that will lead to a non-separate call and all the processors that will lead to separate callbacks. The set of 
required request queue locks is composed of the processors that will lead to separate calls. The operation 
defines two sets for these two categories: greguired^csJoch and g required _rq Jocks- 
Each processor initially has its own call stack lock as its obtained call stack lock. This 
call stack never gets unlocked. This means that other call stack locks cannot be obtained; they 
must be retrieved through lock passing. The condition of the inference rule expresses this: \/x S 
Srequired cs locks ' o" .csJocks{p) .has{x) . The Operation can be assured that p did not pass its own call 
stack lock because otherwise p would be waiting. The remaining required call stack locks are the ones 
for the processors that will lead to separate callbacks. Note that the lock passing conditions are not 
sufficient to guarantee that the call stack locks for separate callbacks are always available. 

As for the request queue locks, the operation calculates gmissing rq locks as the required request queue 
locks minus the already owned request queue locks. The already owned request queue locks are the 
previously obtained request queue locks and the retrieved request queue locks. In the synchronization 
step, the operation must obtain the difference. If this is not possible because some of the missing request 
queue locks are not available, then the operation must wait. The check_pre_and_lock_rqs operation 
takes care of this; it takes g,nissing rq locks and the feature /. Once the execution succeeds, p has the request 
queue locks of gmissing rq locks and the precondition of / holds. 

The apply operation can be assured that each processor g, whose obtained request queue lock the 
operation got in the synchronization step, must be in possession of its call stack lock. If g was not in 
possession of its call stack lock, it must have passed its locks. This means that g is executing a feature 
call and still waiting for the locks to return. In order to execute the feature call, there must have been a 
lock on g's request queue lock so that its action queue can contain the feature call. The request queue 
must still be locked because g is still executing the feature call. Hence, it would not have been possible 
to obtain g's request queue lock. The only exception is the bootstrap processor. However this processor 
only plays a role in the system setup and it never passes its own call stack lock. 

Once the operation got all the required locks, it can execute the body. For once functions it must 
update the once status whenever it writes to the result entity as part of an assignment instruction or as 
part of a creation instruction. For this purpose, it adds a set_not_f resh_with_result operation after 
each assignment instruction or creation instruction. 
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After the execution of the body, the operation has to evaluate the postcondition and it has to make sure 
that the locked request queues get unlocked at the right time. These two steps are performed by another 
operation check_post_and_unlock_rqs that takes the missing request queue locks g,„,-^^,„g locks ^ii^ 
the feature /. This operation evaluates the postcondition either synchronously or asynchronously. After 
the evaluation of the postcondition, the operation enqueues an unlock operation to each request queue 

Smissingj-qjocks- 

SCOOP relies on the Eiffel invariant mechanism. This mechanism is described in Section 7.5 and 
Section 8.9.16 of the Eiffel ECMA standard |9|. On one hand. Section 7.5 describes the semantics of 
invariants: invariants must be satisfied after the execution of every exported routine and after the execu- 
tion of every creation procedure. On the other hand. Section 8.9.16 describes the runtime monitoring of 
invariants: invariants get evaluated on both start and termination of a qualified call to a routine and after 
every call to a creation procedure. We had to decide whether to rely on the semantics of invariants or on 
the runtime monitoring of invariants. We decided to rely on the semantics of invariants for two reasons. 
First, the runtime invariant monitoring mechanism is only one possible implementation of the invariant 
semantics. Second, the runtime invariant monitoring mechanism relies on the notion of unqualified calls. 
However, for simplicity this work assumes feature calls to be in the canonical qualified form. The apply 
operation reflects this decision: the operation evaluates the invariant whenever / is exported. Note that 
the invariant can only contain non-sepaiate target expressions. Hence, each call in the invariant will only 
require /j's call stack lock. 

Finally, the operation has to return the locks and it has to return the result if / is a function. The 
return operation takes care of this. It comes in a variant for queries and in a variant for commands. 
Both variants take the channel a and the caller processor q in order to communicate with q. The variant 
for queries additionally takes the value to be returned to q. 

Before explaining the variants of the apply operation for non-fresh once routines and attributes, 
the discussion continues with the operations that have not been discussed in detail so far, namely 
check_pre_and_lock_rqs, check_post_and_unlock_rqs, and return. 

Check Precondition and Lock Request Queues Operation 

a is fresh 

T\-{p:: check_pre_and_lock_rqs({^i, . . . ,^,„},/);Sp, a) — )• 
{p:: lock({^i,...,^m}); 

provided f .pre-exists then 
eval{a,f .pre)', 
wait (a); 

provided a.data then 

nop 
else 

issue (^1, unlock); 

issue (^m; unlock); 
pop_obtained_rq_locks; 
check_pre_and_lock_rqs({^i, . . . ,qm},f) 
end 
else 

nop 
end; 

The check_pre_and_lock_rqs({<7i, . . .,q,„},f) operation, executed by processor p, takes a proces- 
sor set {^1, . . . ,^m} whose request queues must be locked on behalf of p and it takes a feature / whose 
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precondition must be satisfied. Tiie operation treats the precondition as a wait condition. It goes through 
a number of iterations. Each iteration obtains the request queue locks and then evaluates the precondi- 
tion. If the precondition is satisfied, then the check_pre_and_lock_rqs operation finishes. Otherwise it 
unlocks the request queues and then starts a new iteration. 



Check Postcondition and Unlock Request Queues Operation 

_def , 
q = { 

def ( Ui^i „{{ei,w,i)}Uargs{ei) ife = eQ.w{eu---,e„) 



q = {qi,...,q,„} 

targets ( e) i i^o}^{Ji=o...ntargets{ei) ife = eo.w{ei,...,e„) 
\ {} otherwise 



args{e) 



def 

go G < 



{} otherwise 
(if 

yx G targets {/.post) : (rh o .handler{o .val[p ,controlling_entity{x) .name)) G q)/\ 
-^3{x,y,z) ^ args{f.post),t,h,c: 

(r h jc : t f\controlled{t) f\y.formals{z) : {\,h,c) f\c.isjref) 
then 

q 

otherwise 
{P] 



a is fresh 



T\-{p\: check_post_and_unlock_rqs({^i, . . . ,^,„},/);5p,a) — t- 
{p :: provided /./705f_e;c/5f5 Ago / P then 
issue( 

go, 

execute_delegated( 

eval {a, f. post) ; wait (a) ; 
issue(gi,unlock); . . . ; issue(gy, unlock) 

O.envs{p).top,{qi,...,qm} 

); 

unlock 

); 

pop_obtained_rq_locks 
else 

provided f .post _exists then 

eval {a, f. post) ; wait (a) 
else 

nop 
end; 

issue(^i, unlock); . . . ; i s sue (^m, unlock); 
pop_obtained_rq_locks 
end; 

The check_post_and_unlock_rqs operation also takes a processor set {171 , . . . , q,„} and a feature /. 
The processor set is the same as for the check_pre_and_lock_rqs operation, i.e., the set of processors 
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whose request queues got locked in the synchronization step. The operation first determines whether 
the postcondition should be evaluated synchronously or asynchronously. Then the operation starts the 
evaluation. Finally, the operation enqueues an unlock operation to each request queue in {qi,. . . ,^m}- 

Clarification 5 (Asynchronous postcondition evaluation). The postcondition can be evaluated asyn- 
chronously if every feature call in the postcondition only requires a request queue lock that was obtained 
in the synchronization step and if the postcondition does not involve lock passing. If the postcondition 
has a feature call that requires a lock different from the obtained request queue locks, then p cannot del- 
egate its obtained request queue lock and then continue because the required lock would be required in 
another feature execution context as well. Hence the postcondition must be evaluated synchronously in 
this case. If the postcondition involves lock passing, then one of p's lock might be necessary for the eval- 
uation of the postcondition. Hence, p must pass its locks and cannot proceed until the postcondition is 
evaluated and the passed locks returned. Once again, the postcondition must be evaluated synchronously. 
In Nienaltowski's description of SCOOP p5| a postcondition can be evaluated asynchronously if the cur- 
rent processor is not involved in the postcondition evaluation. This rule permits configurations in which 
the evaluating processor does not have the necessary locks for the evaluation. □ 

If the postcondition can be evaluated asynchronously, then the operation can take one of the proces- 
sors in {^1, . . . ,<7m}- This set does not contain processor p because processor p never obtains its own 
request queue lock. Each processor in this set is exclusively available in the current execution context 
and can thus be used to evaluate the postcondition asynchronously. The check_post_and_unlock_rqs 
operation defines go to be the evaluating processor according to the rule just presented. It also defines 
{gi,. . ■ ,gj} to be the set {qi,. . . ,q„i} minus the request queue lock of go. If p is the evaluating proces- 
sor, then this set is the same as {^i, . . . ,qm}- As a result of these definitions, the postcondition can be 
evaluated asynchronously if go 7^ p. Otherwise, the postcondition must be evaluated synchronously. 

In the synchronous case, processor p evaluates the postcondition, enqueues unlock operations to 
each request queue in {qi , . . . , qm}, and then removes the corresponding locks from its stack of obtained 
request queue locks. The unlock operations will not proceed until the locks have been removed from 
p's stack of obtained request queue locks. In the asynchronous case, processor p must delegate the post- 
condition evaluation to processor go. For this purpose, p enqueues an execute_delegated operation 
to go- The workload involves the postcondition evaluation along with the subsequent issuing of unlock 
operations to all processor in {gi,. . . ,gj}. Processor go unlocks its own request queue after the dele- 
gated execution. The evaluation of the postcondition on go requires the environment that defines the 
values of the entities in the postcondition. Furthermore, the evaluation requires the request queue locks 
{^1, . . .,qm}- These locks are sufficient because the postcondition only gets evaluated asynchronously if 
the evaluation only requires these locks. To satisfy these two requirements, p gives its top environment 
and {^1 ,...,q,„} to go. After go performed the delegated execution, it can unlock its own request queue. 
In the meantime, processor p removes {^1 ,...,qm} from its obtained request queue locks to enable go to 
proceed with the delegated execution. 

The return operation comes in two variants: one for queries and one for commands. 
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Return Operation - Query 

' ifr 7^ void A G.ref _obj{r). class _type. is .exp A o .handler{r) 7^ q 
{Ox, Ox-last Jmported-ref) 
where 



/ / /N def 

a ,r = 



def 



Ox = O.deepjmport{q,r) 
otherwise 

a" a' .pop.env{p) .revoke Jocks{q, p) 



r\- {p returii{a,r,q);Sp,o) — )■ {p :: result{a, r');Sp,o") 



Return Operation - Command 

, def 



o .pop.env{p) .revoke Jocks {q, p) 



r \-{p :: retur-n.{a,q);Sp,o) — )■ 

{p :: provided o .locks 4>assed{q) then notify(a) else nop end;5p,a') 

The variant for queries returns the result and the locks. The variant for commands only returns the 
locks. Both valiants take a channel a and the caller processor q. For queries, the channel is used to 
return the result. For this purpose, the operation takes a reference r that points to the result. Processor q 
is waiting for this result on channel a. This can be seen in the call operation, which issues an apply 
operation and a subsequent wait (a) operation. The apply operation calls the return operation with 
the same channel a. To return the result to q, processor p executes a result on a. The value to be 
returned is not always r directly. If r points to an object of expanded class type and ^ / p, then q must 
deep import the object. In all other cases, q can take r as the return value. An explanation why the deep 



import operation is necessary can be found in Section 5.6.4 For commands, the channel is used to signal 
to q that the locks have been returned in case q passed its locks. This can be determined by looking at the 
state: o. locks _passed{q). In both variants of the return operation, p removes the passed locks from the 
stacks of retrieved locks. In case q did not pass any locks, the removed entries might be the empty set. 
Processor p also removes its top environment because this environment is no longer needed. In case of 
an asynchronous postcondition evaluation, this environment temporarily gets delegated to the evaluating 
processor. 

Until now, the discussion left out the non-fresh once routines and the attributes. Non-fresh once 
functions already have a result. The apply operation just needs to get this result from the state and 
return it. For non-fresh once procedures it does not even have to do this. The only obligation is the 
evaluation of the invariant. The evaluation of the invariant requires the call stack lock of p. This lock is 
given if the condition ^o .locks 4)assed{p) holds. For attributes, note that an instance of ATTRIBUTE is 
also an instance of EXPRESSION. Hence, the operation evaluates the attribute expression and returns 
the result of the evaluation. The invariant does not have to be evaluated in this case. 
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Application Operation - Non-Fresh Once Routine 

/ G ROVTINE A f .is. once A -^o .is .fresh{p J) 
a .handler^ro) = p 

.pass Jocks{q^p J). locks 4>assed{p) 

def 

a' = a. pass Jocks {q,p, l).push_env-withj'eature{p,f, ro, (ri , . . . , r„)) 
dinv fresh 

rh{p :: apply(a,ro,/, {n, . . . ,rn),q~iy,Sp,a) 

{p :: provided f.class-type.inv^exists Af .exported then 
e val , /.class. type . inv) ; wait (a/mO 
else 

nop 
end; 

provided / G FUNCTION then 

return(fl', o' .oncejresult{p,f),q) 
else 

return(a,^) 
end; 

Application Operation - Attribute 

/ G ATTRIBUTE 

O .handle r{ro) = p 

.pass Jocks{q.,p, I). locks. passed{p) 

def 

a' = a.pass.locks{q,p,l).push.env.with.feature{p,f,ro,{)) 
a' is fresh 

rh{p :: a.pply{a,ro,f,{),qJy,Sp,a) 
{p :: eval(a',/); 
wait (a'); 

returii{a, a' .data, q) ; 
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Example 8 (Feature application). This example looks at the application of the feature buy on the first 
investor. This feature is shown in Listing [2] 

Listing 2: Investor class 

class INVESTOR 

create 

make 

feature — Initialization 
make (newJd: INTEGER) 

Create an investor with a new identifier. 

do 

id := new-id 
end 

feature — Access 
id: INTEGER 

The identifier. 

log: separate UUID 

— The identifier of the last market. 

buy {market: separate MARKET, issuer Jd: INTEGER) 

— Buy a share of the issuer on the market, 
require 

market. can Jbuy (Current. /J, issuer Jd) 
do 

market.buy (Current, issuer Jd) 
log := market. id 
ensure 

market. can _sell (Current./t/, issuer Jd) 
end 



end 

The execution starts with a configuration where processor pi finished executing the feature calls in 
feature doJransaction. These feature calls led to one apply operation for the buy feature and one for 
the sell feature in each investor's action queue. 
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P\ 

P2 
P3 

P4 



apply{ae2,r6,buy, (ri,r39),pi, ({},{})); 

apply(fl7o, r6, if'//, (n , rag), pi ,({},{})) | 

apply(a66,r8,/'M3', (n,r39), Pi, ({},{})); 
apply(a74,r8,5e//, (n, rag), pi, ({},{})) 



locks : 

pi :: orq: ({},{p3,p4}) rrq: ({},{}) res: ({},{}) locked 
P2 :: orq: () rrq: () res: () unlocked 
P3 :: orq: () rrq: () res: () locked 
P4 :: orq: () rrq: () res: () locked 
objects : 

> oo {market — )• r i ) , r39 — )• 048 ( 1 ) 
oj5{cash — )■ ri^, available shares 
^ 025 [r2i , ^22] , '"21 023(100), r22 

-> 033[r28],?"28-> 032(1), 

038 [[r34] , [r35]] , r34 041 (0) , r35 



Pi :: 
P2 :: 



ro - 
ri - 
ri6 
r23 
r29 
re - 



r23, owned shares — )• r29), 
024(100), 



■042(0) 



P3 :: re — ;> o^4{id - 
P4 :: r8 04(,{id - 
once status : 
environments : 

pi '.: first Jnvestor - 
first Jnvestor - 

P2 
P3 

Pa 



^37 



043(1) 
■045(2) 



r^^ second Jnvestor 
r^, second Jnvestor 



rs, Current 

rs , issuer Jd 



r39. Current 



At this point, processors p3 and p4 can each take the transition that is described by the inference 
rule for the apply operation for non-once routines. Each processor can then take an additional transition 
by executing the check_pre_and_lock_rqs operation. The result configuration is shown below. The 
channel a-]=, is a fresh channel. Both processors added a new environment that maps the expanded formal 
argument to a copy of the expanded actual argument. In case of processor p3, the copied object is 
referenced by r4o. On processor p4, the copied object is referenced by r4i. Since processor pi did not 
pass its locks, both p3 and p4 added empty lock sets to their stack of retrieved locks. 
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P\ 

P2 
P3 



P4 



l0Ck({/72}); 

eval (^75 , market. can Jjuy (current. id, issuer Jd)); 
wait (075); 

provided a^.data then 

nop 
else 

issue {p2 , unl o ck) ; 
pop_obtained_rq_locks; 
che ck_pr e_and_lo ck_rqs {{pi}, buy) 
end; 

market. buy [current, issuer Jd); 
log := market. id; 

che ck_po st _and_unlo ck_rqs {{P2}, buy) ; 
return(a62,;?i); 

apply(a7o,r6,5e//,(n,f39),;?i, ({},{})) | 
lock({/?2}); 



locks : 

P\ ■ 
P2 ■ 
P3 ■ 

P4 ■ 

objects : 
P\ ■■■ 
P2 ■■■ 



orq: {{}dP3,P4}) rrq: ({},{}) res: ({},{}) locked 



orq: () rrq 
orq: () rrq 
orq: () rrq 



res: () unlocked 
({}) res: ({}) locked 
({}) res: ({}) locked 



ro — > oq {market — ^ r 1 ) , — ^ 04g ( 1 ) 
fi — )• 035{cash —7- ri(,, available shares 
025 [rii , r22] ,r2i^ 023 (100) , r22 - 
'"23 033 [r28] , r28 032 ( 1 ) , 
r29 038 [[r34] , [rss]] , r34 041 (0) , r^s - 

re 044{id^ r3e),r36 043(1), ?"40 - 
r?,i)-,r^l 045(2), ^41 - 



P3 ■■■ 

p^:: r8 045 (/t/ 
once status : 
environments : 

p\ first Jnvestor 
first Jnvestor 

P2 ■■■ 

pT, : : market — )• ri , issuer Jd 
P4 : : market — )• ri , issuer Jd 



^ r23 , owned-shares 
> 024(100), 

^042(0) 
049(1) 
050(1) 



r29), 



re, second Jnvestor 
re, second Jnvestor 



r4o, Current 
r4i, Current 



r8 , Current 

r^ , issuer Jd - 

re 



r39, Current 



The inference rule for the lock operation shows that both p^ and p^ require the request queue lock 
of p2- We decide to give priority to pi,. This leads to the following configuration, where p2^ request 
queue is locked on behalf of p^, : 
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P\ 

P2 
P3 



eval{aj5 , market .can Jjuy {current .id , issuer Jd)); 
wait (0:75); 

provided aj^.data then 

nop 
else 

issue (p2) unlock); 
pop_obtained_rq_locks; 
che ck_pr e_and_lo ck_rqs ( {p2 } , buy) 
end; 

market. buy {current, issuer _id)', 
log := market. id; 

che ck_po St _and_unlo ck_rqs {{P2}, buy) ; 
return(a62,/'i); 

^PP^y{aio, re, sell, {ri,r39),pi, {{},{})) \ 



locks : 
Pi 

P2 
P3 
P4 

objects : 



orq: i{}dP3,P4}) rrq: ({},{}) res: ({},{}) locked 

orq: () rrq: () res: () locked 

orq: {{pi}) rrq: ({}) res: ({}) locked 

orq: () rrq: ({}) res: ({}) locked 



once status : 
environments : 



The evaluation of the precondition produces a result on p2, which is awaited by pj. The result is 
a deep imported object of class type BOOLEAN, referenced by rsg. The boolean value of this object 
indicates that the precondition is satisfied and hence p^ can continue with the execution of the body. In 
the following configuration, the arrays referenced by rig, r23, and ^29 have been updated; the first investor 
bought a share of the issuer. Consequently, the first investor has a lower amount of cash and there is one 
fewer share available. Furthermore, the log attribute of the first investor object has been updated with 
the identifier of the market. This identifier object, referenced by r^s, has been created by p2 in a once 
function of separate type. Hence the object is available as a once result on all processors in the system. 
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( 

/?i :: ••• I P2 :: I 

Pj, :: check_post_and_unlock_rqs({/72};^w3'); 
return(a62,Pi); 

apply(a70,''6,'5e//,(ri, rag), /?!,({},{})) \p4:: ... 
locks : 
objects : 

p\ :: 0(){market ^ ri),rT,i) ^ o^%{\) 

Pi fi — ^ OT,${cash —7- ri^, available shares — ?• r owned shares — )• r29), 
ne ->07l[?-61,''22],''61 070 (90), r22 024(100), 
?"23 073[r62],r62 072(0), 

r29 -^ 075[[?-63],[r35]],r63 -^074(1), ^35 042(0), 

res 077 

;?3 :: re 07s{id ^ rs^Jog r(,s),r^(, 043(1), r4o 049(1), rss 0(,i{true) 

PA :: rs o^eiid ^ rj,i)j3-i 045(2), r4i 050(1) 
once status : 

all:: {MARKET} .id r^s 
environments : 

) 

The postcondition of buy contains the expression current. id with target current. The handler of 
the controlling entity is ^3. Because p3 did not obtain its own request queue lock, it must evaluate the 
postcondition synchronously. After the postcondition evaluation, p^, issues the unlock operation to p2 
and removes p2& request queue lock. This enables p2 to unlock its request queue lock. Processor p-^ 
then executes the return operation to get rid of its top environment and its retrieved locks: 

( 

pi :: ... I P2 :: I P3 apply(a70,''6,5e/Z, (n,r39),/'i, ({}, {})) | /?4 :: ••• 
locks : 

P\ ■■ orq: ({}, {7?3,/'4}) rrq: ({},{}) res: ({},{}) locked 
P2 :: orq: () rrq: () res: () unlocked 
p^, :: orq: () rrq: () res: () locked 
Pa'.', orq: () rrq: ({}) res: ({}) locked 
objects : 

once status : 

environments : 

p\ :'. first-investor ^ r(,, second-investor ^ rg , Current —)• ro / 

first Jnvestor — t- rg , secondJnvestor — )■ rg , issuer Jd — )■ r39 , Current — t- ro 

P2 ■■'■ 
P3 '.'■ 

Pa : : market — )• ri , issuer Jd — )• r4i , Current — )• r% 

) 

□ 



73 



6.4.5 Creation instructions 



A creation instruction has the form create b.f{ei,. . . ,e„) where b is the target entity, / is the creation 
procedure, and ei, . . . ,e„ are the actual arguments. Assume that b is of type {d,g,c). A processor p that 
executes this instruction takes the following steps: 

1 . Processor q creation. 

• If is separate, i.e., g = T, then create a new processor. 

• If ft has an exphcit processor specification, i.e., g = a, then 

- take the processor denoted by a if it already exists. 

- create a new processor if the processor denoted by a does not exist yet. 

• If ft is non-separate, i.e., g = then take p. 

2. Locking. Lock the request queue of q if the following conditions hold: 

• Processor p and processor q are different. 

• Processor p does not have ^'s request queue lock. 

• Processor q does not have p's request queue lock. 

3. Object creation. Ask q to create a new instance with class type c using the creation procedure /. 
Attach the newly created object to b. 

4. Invariant evaluation. If / is not exported, then ask q to evaluate the invariant. 

5. Lock releasing. If ^'s request queue has been locked in the locking step, then ask q to unlock its 
request queue after it is done with the feature request. 

There are four cases in the processor creation step: 

• The entity b has a separate type. 

• The entity b has an explicit processor specification and the denoted processor already exists. 

• The entity b has an explicit processor specification and the denoted processor does not yet exist. 

• The entity b has a non-separate type. 

For each of these cases, there is one inference rule. The discussion starts with the variant where b has 
a separate type. In this case, the instruction defines ^ as a new processor and o as a new object of class 
type c. The reference r points to this object. First the instruction obtains a request queue lock on the new 
processor q so that it can issue statements on q. Next, it writes the value r into the entity b. To make a 
call to the creation procedure, it executes a command instruction. Once this is done, it checks whether 
there is an invariant to evaluate. If / is exported, then the invariant will be evaluated as part of /'s feature 
application. In this case the instruction does nothing. However, if / is not exported, then it must issue the 
invariant evaluation to q. After this step, it can issue an unlock operation to q and remove the request 
queue lock from p's obtained request queue locks. 
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Create Instruction - Top 



{d,h,c) = type.of{T,b) 

h = T 
def _ 



q = O.new4>roc 
o o.newjobj{c) 

de f 

a' = o .add4)roc{q).add-obj{q,o) 

r = o ■rej[o) 
a is fresh 



^rite{b.name,r); 
b.f{ei,...,en); 

provided .class -type. inv^existsV f .exported then 

nop 
else 

issue eval(a,/.c/a55_fy/7e./w); wait(a)) 
end; 

issue unlock); 
pop_obt ained_rq_locks ; 
Sp\q:: nop, a') 

The following discussion looks at the two variants for the cases where b has an explicit processor 
specification. There are two forms of explicit processor specifications: unqualified and qualified. An 
unqualified explicit processor specification, i.e., < a; >, is based on a processor attribute x with an at- 
tached type. The processor denoted by this explicit processor specification is the processor stored in x. 
A qualified explicit processor specification, i.e., < y.handler >, is based on a non-writable entity y of 
attached type. The processor denoted by this explicit processor specification is the same processor as 
the one handling the object referenced by y. A qualified explicit processor specification always denotes 
an existing processor because this specification is based on an attached entity. This means that there is 
already an object attached to this entity and thus its handler must exist. This insight helps to write the 
conditions for the two inference rule variants. 

The variant that handles existing processors states that the specified processor must exist. To check 
this, one must consider both the qualified and the unqualified possibility. For the qualified option, one 
can simply lookup the value of the attribute x. For the unqualified option, one first looks up the value 
of the entity y and then determines the handler of the referenced object. In either case, the result q is 
either the denoted processor or the void value. One then checks whether q is in the set of processors 
of our system. The overall idea of this inference rule is the same as in the case where b has a separate 
type. The difference is in the processor creation, locking, and lock releasing steps. Instead of creating 
a new processor, the instruction takes the existing processor q. \f q = p, then the call to the creation 
procedure will be a non-separate call. In this case, the instruction requires /j's call stack lock. This lock 
is given because otherwise p would be waiting. If p q and q has a lock on p, then the call to the 
creation procedure will be a separate callback. In this case, the instruction requires q's call stack lock. 
This is expressed in the condition with the help of the set grequired cs locks- P ¥^ ^ ^ does not have 
p's request queue lock, then the call to the creation procedure will be a separate call. In this case, the 
instruction must obtain ^'s request queue lock, provided it does not already have this lock. Only when 
it obtained q's request queue lock, does the instruction have to issue an unlock operation and remove q 
from p's stack of obtained request queue locks. 



{p 



create b.f{e\,. . . 
lock({^}); 
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For the variant that handles non-existing processors, one has to verify that the specified processor 
does not exist. To do so, one considers only unqualified processor specifications. In this case, the 
instruction creates a new processor q with a new object o and reference r. The steps in this variant are 
similar to those in the variant where b has a separate type. However, the instruction has to set the value 
of the processor attribute x to the newly created processor. This ensures that the denoted processor will 
be found to exist in the future. 

Create Instruction - Existing Explicit Processor 

{d,h,c) type.of{Y,b) 

h =< x> yh =< y. handler > 

def j a.val{p,x) ift = {d,<x>,c) 

^ I <j.handler{<J.val(p,y)) ift = {d,<y. handler >,c) 
a.procs.has{q) 

def J {^7} ifq p l\ (o.rq Jocks (q). has (p) V <J .cs Jocks (q) .has (p)) 
y {} otherwise 
V-x e grequired^cUocks' -^o .locks^assedip) A o .csJocksip) .has{x) 
o a .new-obj{c) 
a' o.add-obj{q,o) 
r = o .rej[o) 



■> required _cs Jocks 



a is fresh 



T\-{p: \ create b.f{ei,. . . ,en);sp,o) — )• 

{p :: provided^ / p /\^o' .rq Jocks {p). has [q) /\^o' .rqJocks{q).has{p) then 
lock(M) 
else 

nop 
end; 

write (Z?.«ame,r); 
b.f{e\,...,en); 

provided ^f .class. type.inv. exists y f .exported then 

nop 
else 

issue (17, evaLl{a, f .class_type .inv);waLit{a)) 
end; 

provided^ / p /\^o' .rq Jocks [p). has [q) /\^o' .rqJocks{q).has{p) then 

issue unlock); 

pop_obtained_rq_locks 
else 

nop 
end; 
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Create Instruction - Non- Existing Explicit Processor 

(d, h, c) =^ type .of {T, b) 
h=<x> 

-^O .procs.has{o .val{p,x)) 

def 

q = O.new4>roc 
o o.newjjhjic) 

def 

o' = O .add4>roc{q).add.obj{q,o) 

r = o ■rej[o) 
a is fresh 

r :: create b.f{e\,. . .,en);sp, a) 
{p :: write{x.name,q); 
lockilq}); 
vrite(b.name , r); 
b.f{ei,...,en); 

provided ^f .class. type.inv. exists V f .exported then 

nop 
else 

issue (q, eva.l{a, f .class-type .inv) ; wait (a) ) 
end; 

issue unlock); 
pop_obtained_rq_locks; 
Sp\q:: nop, a') 

Lastly, there is a variant for the case where b has a non-separate type. In this case, the instruction 
creates the object on p. Processor creation, locking, and lock releasing is not necessary. The required 
call stack lock on p is given because otherwise p would be waiting. 

Create Instruction - Non- Separate 

{d,h,c) =^ type.of{r,b) 
h = » 

o a.new-obj{c) 

a' o.addj)bj{p,o) 

def I J., . 
r = a .rej (o) 

a is fresh 



r\-{p:: create b.f{e\,. . .,en);sp, o) 
{p :: write(b.name,r); 
b.f{ei,...,e„); 

provided ^f .class _type.inv .existsV f .exported then 

nop 
else 

eval {a,f.classJype.inv) ; wait (a) 
end; 



Example 9 (Object creation). To illustrate object creation, consider a configuration where the root pro- 
cessor pi is executing the root procedure make on the root object oq. This procedure is shown in Listing[3] 



77 



Listing 3: Application class with initialization 

cXass APPLICATION 



create 

make 

feature — Initialization 

make 

— Create a market with investors and issuers. Then do some transactions, 
local 

first Jnvestor. separate INVESTOR 
secondJnvestor. separate INVESTOR 
do 

Create the market with two investors and one issuer. Each investor has 100 units of cash. 

The issuer has one share. 
create market. make (2, 100, 1, 1) 
create first Jnvestor. make (1) 
create secondJnvestor.make (2) 

Do a transaction. 

Current.do -transaction (first Jnvestor, secondJnvestor, 1) 
end 

feature {APPLICATION} — Implementation 
market: separate MARKET 

— The market. 

doJransaction 
end 

The following configuration is our starting point: 

( 

pi :: create market. make {2, 100, 1, 1); 
locks : 

pi :: orq: ({}) rrq: ({}) res: ({}) locked 
objects : 

pi ro — )• oo{market — )• void) 
once status : 
environments : 

pi first Jnvestor — )• void, second Jnvestor — )• void, Current — )• ro 

) 

Processor pi starts executing the creation instruction. The result is a new configuration, where oi is 
the new market object handled by a new processor p2: 
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( 

Pi :: lock({jE'2}); 

wr it e (marto .«ame, ri ) ; 
market .make {2, 100, 1, 1); 
issue(p2)iiiilock); 
pop_obtained_rq_locks; 
... \p2 ::nop 

locks : 

pi :: orq: ({}) rrq: ({}) res: ({}) locked 

P2 orq: () rrq: () res: () unlocked 
objects : 

p\ :: ro — )• 0(){market — )■ void) 

P2 :: n o\ 
once status : 
environments : 

p\ :: first Jnvestor void, secondJnvestor void, Current tq 
P2 ■■■ 

) 

Now processor pi locks the request queue of processor pj. It then stores the reference ri into the 
entity market. With these two steps, processor pi set up the context to execute a feature call to the 
creation procedure make. The resulting feature request will be executed by processor p2. Processor pi 
then asks processor p2 to unlock its request queue after it is done with the feature request. Then processor 
pi removes the obtained request queue lock from its stack. □ 

6.4.6 Flow control instructions 

The if e then St else Sf end instruction executes St if the expression e evaluates to true. Otherwise the 
instruction executes Sf. There is one inference rule for this instruction. In a first step, the instruction 
evaluates the expression e using a fresh channel a and then waits for a notification on a. In a second step, 
it uses the provided operation to either execute St or Sf, depending on the value of the expression. 

If Instruction 

a is fresh 

r\-{p:: if e then st else Sf end; Sp, a) — > 

{p :: eval(a,e); 
wait(a); 

provided a. data then 

St 

else 

^/ 
end; 

The until e loop si end instruction executes a sequence of si instructions until the expression e 
evaluates to true. If e is true initially, then si never gets executed. There is one inference rule for this 
instruction. First, the instruction evaluates e using a fresh channel a. Then it waits for a notification on 
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a. Next, it uses the provided operation to check whether e evaluates to true or false. If e is true, then it 
is done. Otherwise, it executes si followed by another until e loop St end operation. 

Loop Instruction 

a is fresh 

r \-{p :: until e loop si entl;^^, a) 

{p :: eval(a,e); 
wait (a); 

provided a. data then 

nop 
else 

5/; until e loop si end 

end; 

6.4.7 Assignment instructions 

An assignment instruction b:=e assigns the value of the expression e to the entity b. The instruction 
first evaluates the expression e and then waits for a notification on a fresh channel a. Once it gets this 
notification, it uses the write operation to set the value to the entity b. 

Assignment 

a is fresh 

r\- {p b:=e;sp,(j) — >■ {p :: eval(a,e);wait(fl);write(ft. name, a. <iato);5y,, a) 
6.5 Termination 

The system terminates when it reaches a configuration where all action queues are empty, i.e., when 
there is no more work to do. 

7 Conclusion 

In this paper we have presented a formal specification of the SCOOP model, based on operational se- 
mantics. We have demonstrated that this level of rigor is necessary if the specification is to be used as 
a guideline for an implementation. In particular, we were able to clarify a number of omissions and 
ambiguities in the available informal specification, which had gone undetected in other formalizations: 

• Are processor locks fine-grained enough? We require request queue locks and call stack locks. 

• Which locks must be passed? Which locks can be passed? We pass all the locks we actually have. 
We pass these locks both for normal lock passing and for separate callbacks. 

• How do we move object structures from one processor to another processor without violating the 
invariant? The deep import operation must be used. 

• When do we set the status of a fresh once routine to non-fresh? The status of the once routine must 
be set to non-fresh before deep importing. 
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• When can a postcondition be evaluated asynchronously? The postcondition can be evaluated asyn- 
chronously if every feature call in the postcondition only requires a lock that was obtained in the 
synchronization step and if the postcondition does not involve lock passing. 

Because of the complexity of the SCOOP model, our resulting specification is large, the management of 
which is a challenge for a fully formal development. To address this problem, we used abstract data types 
and a notation with an object-oriented flavor, which made the specification more readable and more easily 
extendable, without sacrificing any of the rigors of operational semantics. Furthermore, we introduced a 
distinction between two kinds of statements, namely instructions (user syntax) and operations (run-time 
syntax). This made it possible to treat within one inference system both the actual language elements 
and the implementation details of the runtime system, and to distinguish clearly between them. 

The main application of this work is to guide the implementation of the SCOOP model. This has led 
to a successful implementation of SCOOP on top of the Eiffel language, which supersedes the previous 
prototype implementation and is publicly available pT| . The SCOOP model can however be imple- 
mented on top of any object-oriented language (support for contracts, as offered by Java or Spec#, is 
beneficial), and our work also facilitates such future implementation efforts. In the case of Java, first 
steps towards such an implementation have been taken p2| , which could certainly be supported by our 
work. 

A number of other applications of our semantics can be envisioned. First, the semantics can be 
used to prove correct various properties of the model which have so far only been postulated, such as 
absence of object-level data races and type safety (absence of traitors). In light of the complexity of 
the full model, these properties are no longer obvious. For example, as processor locks serve as an 
abstraction only, it must be shown that locks are not misused in situations such as separate callbacks, 
which involve call stack locks. Second, our operational semantics can also be used to prove correct an 
axiomatic semantics for the SCOOP model, which is planned for future work. In the case of sequential 



Eiffel, a similar development is documented in |26 1. Third, we feel our semantics is detailed enough that 
its rules can directly be implemented as an interpreter for SCOOP programs. Such an interpreter could 
serve as a true reference implementation, which could in turn be used for conformance checking of real 
implementations. 
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